Заплати троллю: лицензии на программы и право продавать свой проект

1. Галочка «Я согласен»

1.1. Договор, который никто не читал

Отметку «Я прочитал лицензионное соглашение и согласен с условиями» каждый ставил сотни раз, и почти никто при этом не читал соглашение. Это проверено опытом. Исследователи предложили 543 студентам зарегистрироваться в новой социальной сети, которой на самом деле не существовало. Три четверти участников, 74 %, вообще не открыли политику конфиденциальности: они выбрали кнопку быстрой регистрации. Те, кто открыл, потратили на неё в среднем 73 секунды, хотя текст требовал получаса чтения; на пользовательское соглашение ушла 51 секунда вместо шестнадцати минут. В соглашение были вписаны два пункта: данные пользователя передаются спецслужбам и работодателям, а платой за доступ служит первенец участника. Их не заметили 98 % согласившихся.

С точки зрения права эта отметка не формальность. Гражданский кодекс разрешает заключать лицензионный договор на программу в упрощённом порядке: условия показаны на экране или напечатаны на упаковке, а согласием считается само начало использования. Письменная форма договора при этом соблюдена. Пират с картинки в начале страницы заключил договор, даже если не прочёл ни строчки.

Пользователю это редко чем-то грозит: он запускает программу и забывает о соглашении. У разработчика положение другое. Он встраивает чужую программу в свою, и условия, на которых она ему досталась, переходят к его продукту. Не прочитанное соглашение о библиотеке превращается в не выполненную обязанность перед её автором.

1.2. Мост и тролль

В сказках под мостом живёт тролль и берёт плату с каждого, кто хочет перейти реку. Чужой код – такой мост. Написать свой игровой движок, свою библиотеку для нейросетей или свой разбор формата спутниковых снимков значит потратить годы; готовое решение переносит на другой берег за вечер. Но мост построен не вами, и у строителя есть условия.

Плата бывает трёх видов. Проприетарная программа берёт деньгами: купите лицензию и соблюдайте соглашение. Программа под разрешительной лицензией просит упоминания: сохраните имя автора и текст лицензии. Программа под лицензией с копилефтом требует взаимности: если отдаёте продукт с её кодом другим людям, отдавайте и собственный код на тех же условиях. Что именно означает каждое из этих слов, разберёт раздел 3.

Тролли тоже бывают разные. Честный называет цену заранее: она написана в лицензии, и прочитать её можно до того, как ступишь на мост. Нечестный прячется и ждёт, пока прохожий дойдёт до середины: такие зарабатывают на чужой невнимательности, и о них пойдёт речь в разделе 2.8. Защита от обоих одна – знать условия до начала работы.

1.3. Что такое лицензия

Программа охраняется авторским правом с той минуты, как написана. Автору принадлежит исключительное право: только он решает, кто и как может её копировать, изменять и распространять. Закон формулирует это жёстко: отсутствие запрета не считается согласием. Если автор ничего не разрешил, значит, не разрешено ничего.

Лицензия и есть такое разрешение. Автор сохраняет своё право за собой, а другим людям позволяет пользоваться программой определёнными способами и на определённых условиях. Отсюда правило, с которого начинается любая проверка.

На GitHub это правило знакомо каждому, кто создавал репозиторий: поле выбора лицензии можно оставить пустым. Тогда, как объясняет справка самой площадки, действует обычное авторское право: автор сохраняет все права, и никто не может воспроизводить, распространять и изменять его работу. Условия площадки позволяют другим пользователям только просматривать такой репозиторий и создавать его копию внутри GitHub. Скачать этот код и вставить в свой проект нельзя, даже если он открыт для всех.

Любую лицензию удобно читать, задавая три вопроса: что она разрешает, что требует взамен и за что автор не отвечает. Разрешительная лицензия MIT умещается в три абзаца и отвечает на них почти дословно: разрешено всё, включая продажу; требуется сохранить уведомление об авторстве и текст лицензии; гарантий нет. Соглашение крупной коммерческой программы занимает десятки страниц, но вопросы к нему те же.

Условия у разных авторов разные, и выглядят они так, а не иначе, не случайно: каждая известная лицензия была ответом на спор своего времени. Чтобы понимать лицензии, полезно знать эти споры.

2. Откуда взялись лицензии

У каждой известной лицензии есть дата рождения и причина. Причины легко запомнить, потому что это истории о людях, которым чужие условия помешали работать. Зная их, проще понять, почему одна лицензия просит лишь упомянуть автора, а другая требует открыть весь код.

2.1. Когда программы ничего не стоили

В 1950-е и 1960-е годы программы не продавали. Вычислительная машина стоила как здание, и программы поставлялись вместе с ней, как инструкция: с исходными текстами и без запретов. Пользователи машин IBM с 1955 года объединялись в группу SHARE, правили системные программы и обменивались ими. Лицензии на программы были не нужны: отдельного товара не существовало.

Положение изменили два события. В июне 1969 года IBM, против которой за полгода до того начали антимонопольное дело, объявила отдельные цены на программы и услуги. У программы появилась цена, а вместе с ней вопрос, что именно покупатель получает за деньги. Затем появились персональные компьютеры и любители, которые копировали программы друг для друга так же свободно, как раньше это делали в вычислительных центрах. В феврале 1976 года Билл Гейтс, совладелец небольшой тогда фирмы, напечатал «Открытое письмо любителям»: интерпретатором Бейсика для компьютера Altair пользуются почти все его владельцы, а заплатили немногие. За машину платить принято, писал он, а программами привыкли делиться; большинство любителей попросту ворует программы, и кто же после этого станет делать профессиональную работу даром.

Закон последовал за рынком. В декабре 1980 года Конгресс США дополнил закон об авторском праве положением о компьютерных программах, и с тех пор программа охраняется так же, как книга. Три года спустя суд подтвердил, что охраняется не только исходный текст, но и машинный код, в том числе код операционной системы, записанный в микросхему. Программа стала собственностью, исходный текст – коммерческой тайной, а лицензия – договором, который перечислял, чего покупателю делать нельзя.

2.2. Принтер, который нельзя починить

Около 1980 года лаборатории искусственного интеллекта Массачусетского технологического института подарили лазерный принтер Xerox. Он часто заминал бумагу, и программист лаборатории Ричард Столлман хотел сделать с ним то же, что сделал с прежним принтером: дописать в управляющую программу сообщение для всех, чьи задания стоят в очереди. Но программа поставлялась только в двоичном виде. Сотрудник другого университета, у которого исходный текст был, отказался им поделиться: он подписал соглашение о неразглашении.

Для Столлмана это был отказ не технический, а нравственный: человека лишили возможности помочь соседу. 27 сентября 1983 года он объявил о проекте GNU – полной операционной системе, которую получит даром каждый, кто может ею пользоваться. Позже требования к такой программе были записаны как четыре свободы: выполнять программу в любых целях, изучать и изменять её, передавать копии, передавать копии своих изменённых версий. Они и стали определением свободной программы. В октябре 1985 года для поддержки проекта был создан Фонд свободного программного обеспечения.

Оставалось решить юридическую задачу. Если просто отдать программу в общественное достояние, любая фирма возьмёт её, улучшит и закроет: улучшенная версия свободной уже не будет. Столлман перевернул авторское право: автор сохраняет права на программу и пользуется ими для того, чтобы запретить запрещать. Каждый, кто распространяет программу или её переделку, обязан передать получателю те же свободы вместе с исходным текстом. Приём получил название копилефт (copyleft), в пику слову copyright. Оно пришло из шутки: на конверте письма, которое получил Столлман, стояло «Copyleft – all rights reversed», то есть «все права перевёрнуты» вместо привычного «все права сохранены».

В феврале 1989 года условия были сведены в один текст – Универсальную общественную лицензию GNU (GNU General Public License, GPL). Вторая версия вышла в 1991 году, третья – в 2007-м.

2.3. Университетские лицензии

Одновременно сложилась другая традиция, и тоже в университетах. Калифорнийский университет в Беркли распространял свою версию системы Unix, Массачусетский технологический институт – оконную систему X. Цель у авторов была иная: чтобы результатом пользовалось как можно больше людей и компаний, в том числе в закрытых продуктах. Их лицензии укладывались в несколько абзацев: делайте что хотите, только сохраните уведомление об авторстве и не предъявляйте нам претензий. Отдать код просто в общественное достояние авторы системы X тоже пробовали, но крупная компания отказалась работать с кодом, на котором нет явного уведомления о правах. Так во второй половине 1980-х появились лицензии MIT и BSD, которые теперь называют разрешительными.

В лицензии BSD был ещё один пункт: в любой рекламе продукта следовало упоминать университет. Когда той же формулой стали пользоваться другие авторы, подставляя свои имена, упоминания начали складываться: в одной из систем 1997 года их набралось 75. В 1999 году университет этот пункт отменил; осталась лицензия из трёх пунктов, а позже появилась и из двух.

Третья известная разрешительная лицензия выросла из проекта веб-сервера Apache. Её вторая версия, принятая в январе 2004 года, ответила на вопрос, которого в 1980-е никто не задавал: что, если автор кода владеет патентом на то, что этот код делает? Apache-2.0 прямо даёт получателю право пользоваться такими патентами и отбирает это право у того, кто сам подаст патентный иск из-за этой программы.

2.4. Linux, Netscape и слова «открытый код»

В сентябре 1991 года финский студент Линус Торвальдс выложил в сеть ядро операционной системы. Первая его лицензия была самодельной и запрещала брать за распространение деньги, даже плату за пересылку. Уже в январе 1992 года он объявил, что переходит на GPL: его просили снять запрет на плату, а условие копилефта его устраивало. Ядро Linux вместе с программами проекта GNU стало системой, на которой сейчас работает бо́льшая часть серверов и все телефоны с Android, и самым известным доказательством того, что копилефт не мешает промышленному применению.

В январе 1998 года компания Netscape, проигрывая в конкуренции браузеров, объявила, что откроет исходный код своего. Для этого ей понадобилась лицензия, которая устраивала бы и сообщество, и юристов корпорации; так появилась лицензия Mozilla (MPL) с копилефтом, ограниченным отдельными файлами. В начале февраля того же года группа разработчиков придумала для свободных программ новое название, понятное бизнесу, – open source, открытый код. Тогда же была создана организация Open Source Initiative (OSI), которая проверяет лицензии на соответствие определению открытого кода. Свободные программы и открытый код – почти одно и то же множество программ, названное с двух сторон: первое название говорит о свободе пользователя, второе – о способе разработки.

2.5. Не только код

К началу 2000-х выяснилось, что лицензии для программ плохо подходят для текстов, музыки и изображений. В декабре 2002 года организация Creative Commons выпустила набор лицензий, из которых автор собирает нужную, как из кубиков: с указанием авторства, с запретом коммерческого использования, с запретом переделок, с требованием распространять производные работы на тех же условиях. В 2009 году к ним добавился отказ от прав CC0. Для баз данных и шрифтов появились свои лицензии. Всё это понадобится в разделе 3.5: в проекте есть не только код.

2.6. GitHub и код без лицензии

В апреле 2008 года заработал GitHub, и публиковать код стало так же просто, как сохранять файл. У простоты оказалась цена: код выкладывали, не думая о лицензии вовсе. В 2013 году GitHub открыл сайт choosealicense.com, который сводит выбор лицензии к нескольким вопросам, а в 2015-м сам посчитал итог: лицензия была примерно у 20 % репозиториев. Весь остальной код формально нельзя использовать, хотя авторы, скорее всего, хотели обратного. По оценке аналитиков 2026 года, картина с тех пор не изменилась: лицензии нет у четырёх проектов из пяти.

2.7. Облака против авторов

Следующий спор начался, когда программы стали продавать как услугу. Облачный провайдер берёт открытую базу данных, разворачивает её на своих серверах и сдаёт в аренду. Копии программы он никому не передаёт, поэтому условия копилефта не срабатывают, а платить разработчикам базы он не обязан. Компании, которые эти базы создавали, сочли такой порядок несправедливым и стали менять лицензии.

В октябре 2018 года MongoDB перешла на собственную лицензию SSPL: кто предлагает программу как услугу, обязан открыть код всей системы, которая эту услугу обеспечивает. За ней последовали другие: в 2021 году – поисковая система Elasticsearch, в 2023-м – инструмент управления инфраструктурой Terraform, в 2024-м – база данных Redis. Организация OSI такие лицензии открытыми не признала: они ограничивают круг разрешённых применений. Для них закрепилось название «лицензии с доступным исходным кодом» (source-available).

Сообщество отвечало ответвлениями: от последней открытой версии отделялся независимый проект. Так появились OpenSearch, OpenTofu и Valkey. Часть компаний после этого сделала шаг назад: Elastic в 2024 году и Redis в 2025-м добавили открытую лицензию AGPL как один из вариантов на выбор.

Тот же урок, но с проприетарной лицензией, получили разработчики игр. В сентябре 2023 года компания Unity объявила, что с января начнёт брать плату за каждую установку игры, сделанной на её движке. Студии, которые строили на движке годами, обнаружили, что условия можно изменить в одностороннем порядке. Через десять дней условия смягчили, а ровно через год плату отменили совсем.

2.8. Тролли

Осталось рассказать о тех, кто сидит под мостом в засаде. Патентным троллем называют фирму, которая сама ничего не производит, а скупает патенты и зарабатывает, предъявляя их другим: ответчику дешевле заплатить, чем судиться. Один производитель телефонов в 2006 году заплатил такой фирме 612,5 миллиона долларов. От подобных исков и защищают патентные оговорки в Apache-2.0 и GPL-3.0. У авторского права есть свои тролли, и интереснее всего, что они нашлись и внутри мира свободных лицензий.

Один из разработчиков сетевого экрана ядра Linux несколько лет рассылал немецким компаниям требования о нарушении GPL. Нарушения были настоящими, но целью было не исправление, а деньги. Первое требование было скромным, несколько тысяч евро, и компания подписывала обязательство больше не нарушать; за каждое следующее нарушение по этому обязательству полагался штраф, и суммы доходили до сотен тысяч. Требования получили больше пятидесяти компаний. Схема держалась на том, что вторая версия GPL прекращает лицензию при любом нарушении сразу и без срока на исправление. В октябре 2017 года разработчики ядра ответили общим заявлением: они обязались давать нарушителю тридцать дней на исправление и осудили принуждение ради выгоды.

Вторая история связана с ранними версиями лицензий Creative Commons. По ним любая ошибка в указании автора тоже прекращала лицензию немедленно. Нашлись фотографы, которые выкладывали снимки под такими лицензиями, автоматически отыскивали сайты, где подпись оформлена не по правилам, и требовали компенсацию. В версии 4.0 лицензию исправили: права восстанавливаются, если ошибка устранена в течение тридцати дней после того, как нарушитель о ней узнал. Но снимки под старыми версиями никуда не делись. Отсюда два практических правила: брать материалы под лицензиями версии 4.0 и оформлять подпись полностью – автор, название, лицензия, ссылка, отметка об изменениях.

В России роль троллей играют фирмы, которые получают от фотографов права на снимки и автоматически ищут сайты, где эти снимки остались. Летом 2025 года в Государственной думе такую практику назвали юридическим экстремизмом и оценили её масштаб в восемь тысяч дел. В ответ в Гражданский кодекс внесли поправки о соразмерной компенсации; о них – в разделе 5.5.

Честное принуждение выглядит иначе. В 2003 году выяснилось, что в маршрутизаторе Linksys WRT54G работает Linux, а исходных текстов производитель не предоставил. Под давлением сообщества компания их опубликовала, и из этого кода вырос проект OpenWrt – свободная прошивка для множества моделей маршрутизаторов. Годом позже суд в Мюнхене запретил продавать устройство с кодом под GPL без соблюдения её условий; это было первое судебное подтверждение того, что GPL имеет юридическую силу. Цель в обоих случаях – публикация исходных текстов, а не деньги, требования открыты, а нарушителю дают время исправиться.

Почитать на Хабре: «Почему корпорации зарабатывают миллиарды на „бесплатном“ коде. История Open source» – связный рассказ об открытом коде с 1950-х годов; «Когда вендор меняет правила игры: риски смены лицензий БД и что с этим делать» – хронология смен лицензий у баз данных; «Разбираемся с лицензией Redis. И что выбрать продуктовой команде».

Вывод из всех этих историй один: лицензию читают до того, как начинают пользоваться кодом, а условие выполняют точно, даже если оно кажется формальностью. Какие именно условия бывают, разберёт следующий раздел.

3. Какие бывают лицензии

История оставила после себя сотни текстов: в списке SPDX, которым пользуются сканеры и реестры пакетов, их больше семисот. На практике хватает одной оси и семи делений на ней. Ось – то, сколько прав автор оставляет себе и сколько отдаёт получателю.

3.1. Спектр

Первые пять столбцов считаются открытым кодом: такие лицензии позволяют любому человеку использовать, изучать, изменять и распространять программу, в том числе за деньги. Определение открытого кода состоит из десяти критериев, и два из них объясняют границу на рисунке: лицензия не может запрещать продажу программы и не может ограничивать области её применения, включая коммерческую. Поэтому два правых столбца открытым кодом не являются, даже если исходный текст опубликован, а пометка «только для некоммерческого использования» выводит лицензию из числа открытых. Пройдём по столбцам слева направо.

3.2. Отказ от прав

Автор может отказаться от своих прав настолько, насколько позволяет закон, и передать произведение в общественное достояние. Для этого служат CC0 от Creative Commons и текст под названием Unlicense. Взамен не требуется ничего, даже упоминания. В большинстве стран, включая Россию, от авторства отказаться нельзя, поэтому оба текста устроены в два слоя: сначала отказ, а на случай, если он недействителен, – разрешение делать с произведением что угодно.

Так распространяются многие наборы игровой графики и звуков и часть наборов данных. База данных SQLite тоже передана авторами в общественное достояние. У такого отказа есть один подвох: CC0 прямо оговаривает, что патентные права автора не передаются, поэтому для программ её применяют редко.

3.3. Разрешительные лицензии

Разрешительная лицензия (permissive license) позволяет всё, включая продажу и включение в закрытый продукт, и просит одного: сохранить уведомление об авторских правах и текст самой лицензии. Это плата упоминанием.

• MIT. Три абзаца: разрешение, условие, отказ от гарантий. Под ней распространяются React, Vue, Node.js, игровой движок Godot.
• BSD в вариантах из двух и трёх пунктов. Третий пункт запрещает использовать имя автора для рекламы производных продуктов. Под BSD выходят PyTorch и NumPy; PostgreSQL использует близкий к ней собственный текст.
• Apache-2.0. Текст длиннее, потому что закрывает два вопроса, о которых MIT молчит. Первый – патенты: каждый участник проекта явно разрешает использовать свои патенты, воплощённые в его вкладе, а тот, кто подаст патентный иск из-за этой программы, теряет лицензию. Второй – порядок упоминания: изменённые файлы нужно пометить, а если у проекта есть файл NOTICE, его содержимое должно попасть в ваш продукт. Под Apache-2.0 выходят TensorFlow, Kubernetes, исходный код Android, OpenCV начиная с версии 4.5.

3.4. Копилефт

Копилефт (copyleft) требует взаимности: получив свободу пользоваться кодом, вы обязаны дать такую же свободу тем, кому передаёте результат. Насколько далеко тянется это требование, зависит от силы копилефта.

Слабый копилефт ограничивается самим компонентом. LGPL писалась для библиотек: закрытая программа может ими пользоваться, но изменения в самой библиотеке нужно открыть, а пользователю оставить возможность заменить библиотеку своей сборкой. Поэтому библиотеки под LGPL обычно подключают динамически. Под LGPL выходят Qt для Python (PySide6) и FFmpeg в сборке по умолчанию. MPL-2.0 проводит границу по файлам: изменённые файлы компонента остаются открытыми, новые файлы рядом с ними могут быть под любой лицензией. Так лицензирован Firefox.

Сильный копилефт распространяется на всю программу. По GPL всё, во что вошёл её код, можно передавать другим только на условиях GPL и вместе с исходным текстом. Запретить продажу GPL не позволяет, но продавать приходится программу с открытым кодом. Под GPL выходят ядро Linux, Git, Blender, WordPress, QGIS.

Условие GPL срабатывает при передаче копий. Пока программа работает внутри команды или на собственном сервере, копии никому не передаются, и обязанность открывать код не возникает. Этим долго пользовались веб-сервисы, построенные на коде под GPL.

Сетевой копилефт закрывает именно эту возможность. AGPL-3.0 повторяет GPL-3.0 и добавляет один пункт: если изменённая программа доступна пользователям по сети, им нужно предложить её исходный код. Под AGPL выходят система мониторинга Grafana и, что важно для проектов с компьютерным зрением, библиотека Ultralytics с детекторами YOLO. Разница между ними существенна. Grafana обычно работает рядом с вашей программой как отдельный, не изменённый инструмент, и на ваш код её лицензия не влияет. Библиотека Ultralytics подключается внутрь вашего кода, и тогда программа целиком становится работой на её основе: по словам самих разработчиков, AGPL подходит тем, кто готов открыть весь свой проект.

3.5. Лицензии не для кода

Картинке, тексту, музыке и набору данных лицензии для программ подходят плохо: в них говорится об исходном и объектном коде. Для таких произведений принято семейство Creative Commons. Каждая лицензия собирается из четырёх условий:

CC BY можно использовать в коммерческом продукте, указав автора. CC BY-SA – тоже, но переработанный материал придётся отдать на тех же условиях; так лицензированы Википедия и ответы на Stack Overflow. Пометка NC закрывает дорогу к продаже. Для наборов данных есть своя лицензия с условием «на тех же условиях» – ODbL, под ней распространяются данные OpenStreetMap. Для шрифтов – SIL Open Font License: шрифт можно встроить в коммерческий продукт, но нельзя продавать отдельно.

Для программного кода сами Creative Commons свои лицензии применять не советуют; исключение – CC0.

3.6. Доступные исходники и проприетарные программы

Лицензии с доступным исходным кодом (source-available) появились в споре с облачными провайдерами, описанном в разделе 2.7. Исходный текст опубликован, его можно читать, менять и запускать у себя, но одно применение запрещено или обложено условием. SSPL требует от того, кто предлагает программу как услугу, открыть код всей обслуживающей её системы, что для облачного провайдера невыполнимо. BUSL запрещает коммерческое использование в оговорённых автором случаях, а через срок не больше четырёх лет превращается в обычную открытую лицензию. Обычному проекту, который использует такую базу данных внутри себя, эти лицензии не мешают. Мешают они тому, кто захочет продавать саму эту базу как сервис.

Проприетарная программа распространяется по лицензионному соглашению с пользователем (EULA), и разрешено по нему только то, что прямо названо. Внутри этой группы различают несколько привычных видов. Бесплатная программа (freeware) не стоит денег, но исходники закрыты и права ограничены. Условно-бесплатная (shareware) и пробная версии работают ограниченное время или с урезанными возможностями. Учебная лицензия выдаётся бесплатно студентам и преподавателям и почти всегда запрещает коммерческую разработку. Лицензии игровых движков берут плату после порога дохода.

3.7. Совместимость: улица с односторонним движением

В проекте редко бывает одна лицензия, и вопрос звучит так: можно ли соединить код под лицензией А с кодом под лицензией Б в одной программе? Ответ есть, только если существует лицензия, условия которой удовлетворяют обеим.

Общее правило простое: код движется от более свободных лицензий к более требовательным, но не обратно.

Код под MIT можно включить в проект под Apache-2.0, под GPL и в закрытый продукт: условие MIT выполнимо везде. Код под GPL можно включить только в проект под GPL: его условие требует, чтобы вся программа была под GPL, а закрытый продукт этому противоречит. У этой улицы есть и тупик. Вторая версия GPL не сочетается ни с Apache-2.0, ни с третьей версией самой GPL: каждая из них добавляет условия, которых во второй версии нет, а GPL дополнительных условий не допускает. Проблему снимает пометка «версии 2 или более поздней» (or later): получатель сам выбирает версию. Именно поэтому в идентификаторах SPDX различают GPL-2.0-only и GPL-2.0-or-later. Ядро Linux и Git выпущены строго под второй версией, а WordPress и FFmpeg – с пометкой «или более поздней».

Некоторые проекты выпускают под двумя лицензиями сразу: открытой с копилефтом и платной коммерческой. Так поступают Qt, MySQL и Ultralytics. Тот, кто готов открыть свой код, берёт программу бесплатно; тот, кто не готов, покупает право этого не делать. Это единственный случай, когда автор кода под GPL может продать вам избавление от копилефта: права на весь код принадлежат ему.

3.8. Сводная таблица

Почитать на Хабре: «Лицензия для вашего open-source проекта» – большой обзор с разбором текстов; «Опенсорс лицензии: большой разбор лицензий GNU» – взгляд юриста на GPL, LGPL и AGPL; «Лицензии слабого копилефта: могут ли они заменить пермиссивные (разрешительные) лицензии?».

Таблица описывает, что лицензии разрешают. Что из этого разработчики выбирают на самом деле, видно по данным.

4. Что выбирают сейчас

Спектр из раздела 3 показывает, какие лицензии бывают. Какие из них встречаются на деле, можно не гадать, а посчитать: GitHub раз в квартал публикует открытые данные о том, под какими лицензиями идёт работа на площадке. Рисунки этого раздела построены по этим данным, скачанным 12 октября 2026 года.

4.1. Что именно посчитано

Набор данных называется GitHub Innovation Graph. Для каждой лицензии в нём записано, сколько разработчиков за квартал хотя бы раз отправили изменения в открытый репозиторий с такой лицензией. Это мера живой работы, а не числа репозиториев: заброшенный проект в неё не попадает, а крупный проект с сотнями участников весит много.

У меры три ограничения, о которых нужно помнить, глядя на рисунки. Репозитории без лицензии в набор не входят вовсе, так что все доли считаются среди лицензированных проектов. Лицензию определяет программа по файлу LICENSE; если файл составной или нестандартный, проект попадает в строку «не распознана». И разработчик, который работал в проектах с разными лицензиями, учтён в каждой из них.

4.2. Половина – MIT

В первом квартале 2026 года половина всей работы в лицензированных репозиториях, 50,1 %, шла под лицензией MIT. На втором месте Apache-2.0 с 14,8 %, на третьем GPL-3.0 с 9,3 %. Три лицензии вместе дают почти три четверти. Если сложить по типам, на разрешительные лицензии приходится 67,9 %, на копилефт всех видов – 15,7 %; ещё у 13,8 % лицензия есть, но не распознана.

Россия от мира отличается мало. Доля MIT почти та же, 49,3 %. Apache-2.0 встречается реже, 11,7 % против 14,8 %, а GPL-3.0 чаще: 11,1 % против 9,3 %. Заметнее всего расхождение у лицензии-отказа Unlicense: 1,8 % против 0,8 %.

4.3. Копилефт меняет состав

За шесть лет доля MIT выросла с 44,9 до 50,1 %. Доля GPL-3.0 снизилась с 11,6 до 9,3 %, GPL-2.0 – с 2,5 до 1,7 %. А доля AGPL-3.0 выросла больше чем вдвое, с 1,5 до 3,2 %, и это теперь пятая лицензия площадки. Копилефт не исчезает, а меняет состав: классическая GPL уступает место сетевой.

Если отойти дальше, движение ещё заметнее. В подсчёте самого GitHub за 2015 год на вторую версию GPL приходилось 13 % лицензированных проектов, а на AGPL – один процент. По данным компании, которая проверяет лицензии в коммерческих продуктах, в 2012 году на копилефт приходилось 59 % компонентов среди десяти самых частых лицензий, а в 2021-м – 22 %. Перелом пришёлся на середину 2010-х годов, и с тех пор соотношение держится около четырёх к одному в пользу разрешительных лицензий.

Рост AGPL совпадает по времени со спором из раздела 2.7: в 2021 году на неё перешла Grafana, в 2024-м и 2025-м её добавили Elastic и Redis. Объяснение напрашивается само: лицензию выбирают те, кто хочет остаться открытым проектом и при этом не дать сдавать свой код в аренду. Но это толкование, а не измерение.

4.4. Чего нет на рисунках: код без лицензии

Все числа выше относятся к проектам, у которых лицензия есть. Таких меньшинство. В 2015 году GitHub насчитал лицензию примерно у 20 % репозиториев. Исследование 2026 года охватило 131 миллион проектов со всех открытых площадок: лицензии нет у 83 % из них.

Это число можно проверить самому. При подготовке конспекта через поиск GitHub были пересчитаны репозитории, созданные в тридцать выборочных дней с 2012 по 2026 год, всего 2,2 миллиона. Лицензия нашлась у 10,2 % из них. Для 2014 года тот же способ даёт 19,8 %, то есть воспроизводит число самой площадки; с 2021 года доля держится между 8,6 и 10,1 %.

Картина зависит от строгости отбора. Среди всего открытого кода без лицензии больше четырёх пятых. Среди пакетов, выложенных в реестры, – от 8 % в npm до 24 % в PyPI. Среди компонентов, из которых собраны коммерческие продукты, – 8 %. Чем серьёзнее проект, тем чаще у него есть лицензия, и это объяснимо: без неё им не могут пользоваться другие.

У моделей дела хуже, чем у кода. Из 3,1 миллиона моделей на Hugging Face лицензия не указана у 63,7 %. Среди указавших её около 28 % выбрали условия, которые открытой лицензией не являются: собственный текст автора, лицензии с ограничениями по применению, лицензии производителей моделей, запрет коммерческого использования.

У учебных репозиториев дела не лучше. На московской площадке Mos.Hub, где их особенно много, файл лицензии нашёлся у 16 проектов из выборки в 400: это 4 %.

4.5. Что внутри настоящих продуктов

Осталось посмотреть на зависимости, то есть на то, что окажется в описи проекта. Среди тысячи самых скачиваемых пакетов Python разрешительные лицензии у 919. У 38 пакетов копилефт без разрешительной альтернативы, у 22 лицензия проприетарная, у 15 она в метаданных не указана. Копилефт при этом не прячется в дальних углах: шестой по числу скачиваний пакет, набор корневых сертификатов certifi, распространяется под MPL-2.0, а драйвер базы данных psycopg2 и библиотека paramiko – под LGPL.

В коммерческих продуктах открытый код есть почти всегда. По отчёту 2026 года о 947 проверенных кодовых базах, открытые компоненты нашлись в 98 % из них, в среднем по 1180 на приложение, причём две трети компонентов попали туда не напрямую, а как зависимости зависимостей. Лицензионные конфликты обнаружены в 68 % кодовых баз; годом раньше их было 56 %.

Итог раздела такой. Почти всё, что встретится в проекте, окажется под MIT, Apache-2.0 или BSD. Но «почти всё» не значит «всё»: вывод о продукте определяет не типичная зависимость, а самая требовательная из тысячи. И чтобы понять, чем грозит ошибка, нужно знать, что говорит закон.

5. Что говорит закон

До сих пор речь шла о текстах лицензий. Но условия лицензии были бы пожеланиями, если бы за ними не стоял закон, который делает их обязательными. В России это часть четвёртая Гражданского кодекса. Из неё программисту нужно знать пять вещей: что охраняется, чьё это, как устроена лицензия, что можно делать без спроса и сколько стоит ошибка.

5.1. Программа как литературное произведение

Гражданский кодекс охраняет программы так же, как литературные произведения. Охраняется программа в любой форме: исходный текст, объектный код, подготовительные материалы разработки и то, что программа выводит на экран. Никаких действий для этого не требуется: кодекс прямо говорит, что регистрация произведения и соблюдение иных формальностей не нужны. Право возникает в ту минуту, когда код записан.

Зарегистрировать программу в Роспатенте можно, но это дело добровольное. Регистрация стоит 5000 рублей и занимает около двух недель. Она не создаёт право, а помогает его доказывать: сведения реестра считаются достоверными, пока не доказано обратное. Пользуются этим широко: в 2025 году подано почти 46 тысяч заявок на программы и базы данных, и почти треть российских заявок пришла от вузов.

Так же важно, чего закон не охраняет. Авторские права не распространяются на идеи, методы, способы решения задач и языки программирования. Охраняется текст программы, а не то, что она делает. Суд по интеллектуальным правам формулирует это так: совпадение целей и функций двух программ само по себе не говорит о том, что одна использована в другой. Написать свою программу, которая решает ту же задачу, можно; взять чужой текст – нельзя.

Срок охраны – вся жизнь автора и ещё семьдесят лет. Особого короткого срока для программ нет, так что почти все программы, когда-либо написанные, охраняются до сих пор.

5.2. Чей это проект

Автором закон признаёт только человека, творческим трудом которого создан результат. Те, кто помогал технически, советовал, организовывал работу или контролировал её, авторами не становятся. Преподаватель и куратор практики не соавторы проекта. Не соавтор и участник команды, который только тестировал или вёл доску задач: автор тот, чей творческий труд выражен в коде, графике, музыке, сценарии.

Команда, которая вместе написала программу, – это соавторы, и исключительное право принадлежит им совместно. Если никаких соглашений нет, действуют правила кодекса:

Из таблицы виден главный риск командного проекта. Пока участники вместе, правила удобны. Но один несогласный или просто переставший отвечать на сообщения участник блокирует любую сделку с продуктом: его нельзя ни продать, ни передать заказчику, ни опубликовать под открытой лицензией. Лечится это письменным соглашением соавторов, которое кодекс прямо допускает: кто авторы, как принимаются решения о лицензии и продаже, как делятся доходы, что происходит, когда участник уходит.

Вуз правообладателем учебного проекта не становится. Служебным произведением, права на которое принадлежат работодателю, считается только то, что создано в рамках трудовых обязанностей, а студент с вузом в трудовых отношениях не состоит. Ни пользование аудиторией и компьютерами, ни консультации руководителя прав вузу не дают. Выпускную работу вуз обязан разместить в своей электронно-библиотечной системе, но размещается текст, и из него по решению правообладателя изымаются сведения, имеющие коммерческую ценность.

Иначе обстоит дело, когда проект делается для кого-то. Если студент работает в организации и программа входит в его трудовые обязанности, право принадлежит работодателю. Если программа создана по договору заказа между организациями, право получает заказчик. А если заказ взял сам автор как частное лицо, право остаётся у него, пока в договоре прямо не написано, что оно передаётся заказчику в полном объёме: договор, где этого нет, считается лицензионным.

Те же вопросы задаст любой, кто даёт деньги. Грант «Студенческий стартап» Фонда содействия инновациям – миллион рублей – выдаётся при условии, что права на результат принадлежат созданной студентом компании, а вуз письменно подтверждает, что не претендует на эту интеллектуальную собственность.

5.3. Лицензия как договор

Распорядиться правом можно двумя способами: продать его целиком или выдать лицензию, то есть разрешить использование в оговорённых пределах. Лицензия бывает исключительной, когда автор обязуется больше никому её не выдавать, и простой. Главное правило чтения любой лицензии записано в кодексе: право использования, прямо не указанное в договоре, не считается предоставленным. Чего в тексте нет, того нельзя.

Обычный лицензионный договор заключается письменно. Для программ есть упрощённый порядок, с которого начался конспект: условия показаны на экране или на упаковке, и начало использования означает согласие. А с 2014 года в кодексе есть отдельная статья об открытой лицензии. Это договор присоединения, условия которого доступны всем и размещены так, чтобы с ними можно было ознакомиться до начала использования. MIT, GPL и Creative Commons в кодексе не названы, но именно эта статья делает их действующими договорами.

В статье об открытой лицензии есть и механизм, на котором держится копилефт. Автор может разрешить создавать на основе своей программы новые; тогда считается, что он заранее предложил лицензию каждому, кто захочет пользоваться этой новой программой, на тех же условиях. А если получатель начнёт передавать права другим на иных условиях, автор вправе отказаться от договора и потребовать компенсацию как за использование без лицензии.

Российские суды применяют эту статью. В 2025 году московский арбитражный суд рассматривал иск агентства, требовавшего 40 000 рублей за фотографию стадиона, которую сайт взял из хранилища Википедии. Сайт указал автора и источник, как требовала лицензия CC BY-SA, и в иске было отказано. В решении сказано, что юридическая сила свободных лицензий в России полностью признана и что они считаются лицензионными договорами, заключёнными в упрощённом порядке. Обратный пример дал в том же году суд в Калининграде: клиника поставила на сайт чужое изображение и сослалась на то, что существуют открытые лицензии Creative Commons. Суд ответил, что размещать произведение под такой лицензией – право автора, а не его обязанность, и взыскал 97 500 рублей.

Для программ самое известное российское дело связано с программистом, который собрал свою систему из чужих библиотек под GPL и предлагал её за плату. Когда программой стали пользоваться без его согласия, городской суд отказал ему в защите: автор сам не соблюдал условия лицензий на компоненты. В 2022 году Конституционный суд признал такой отказ недопустимым, и в 2023-м в кодекс внесли поправку: нарушение прав авторов компонентов не лишает защиты того, кто создал из них новую программу. Но ответственность перед авторами компонентов остаётся.

Копилефт всплывает и там, где его не ждут. Чтобы попасть в реестр российского программного обеспечения, нужно владеть исключительным правом на продукт. В сентябре 2026 года суд поддержал отказ включить в реестр офисный пакет, собранный на основе LibreOffice: пять из семи его программ оказались чужими программами под открытыми лицензиями, и заявитель не был правообладателем главной из них.

Стоит честно сказать и о том, чего в практике нет. Российского решения, которое обязало бы нарушителя раскрыть исходный код по GPL, найти не удалось, как и споров о нарушении MIT или Apache в программе. Подать такой иск может только правообладатель кода, а не пользователь, которому не дали исходных текстов.

5.4. Что можно без спроса

Тому, кто законно получил экземпляр программы, кодекс даёт несколько прав, которые не зависят от доброй воли автора. Можно запускать программу и хранить её в памяти компьютера, приспосабливать её к своей технике и исправлять явные ошибки, если договор этого не запрещает. Можно сделать резервную копию. Можно изучать, исследовать и испытывать программу, чтобы понять идеи, на которых она построена. Можно даже декомпилировать её, но только ради того, чтобы своя, независимо написанная программа могла с ней взаимодействовать, и только если нужных сведений нельзя получить иначе.

Привычное право скопировать книгу или песню «для себя» на программы не распространяется: кодекс исключает их прямо.

Ещё одно свободное использование важно для учёбы. Чужое произведение разрешено цитировать в учебных, научных и критических целях, указав автора и источник и не выходя за объём, оправданный целью. Фрагмент чужого кода в отчёте или на слайде с указанием источника – цитата. Тот же фрагмент, включённый в продукт, – уже использование, и на него нужна лицензия.

5.5. Цена ошибки

За нарушение исключительного права правообладатель может потребовать возмещения убытков, но обычно выбирает компенсацию: её размер доказывать не нужно, достаточно доказать само нарушение. С 4 января 2026 года действуют новые правила. Компенсация составляет от десяти тысяч до десяти миллионов рублей, либо двойную стоимость контрафактных экземпляров, либо двойную цену, которую обычно берут за законное использование. Размер определяет суд соразмерно нарушению. Предпринимателю, который не знал и не должен был знать, что нарушает чужое право, твёрдая сумма ограничена полумиллионом.

Есть и отдельная статья о сведениях об авторе и условиях использования. Удалить из чужого файла строку с именем автора и текст лицензии – самостоятельное нарушение с компенсацией от тысячи до ста тысяч рублей.

От статуса нарушителя зависит, нужна ли вина. Учебный проект отвечает, только если виноват, хотя доказывать свою невиновность придётся ему самому. Как только проект начал зарабатывать, ответственность наступает независимо от вины. Прекратить нарушение обязан любой.

Порядок сумм в судебной практике такой. За чужую картинку на сайте взыскивают десятки тысяч рублей. За взломанные профессиональные программы, найденные на компьютерах организации, – от сотен тысяч до миллионов: в делах последних лет это от 762 тысяч до 19,8 миллиона рублей. Уголовная ответственность наступает, когда стоимость прав превышает 500 тысяч рублей, и для команды, работающей на открытых библиотеках, это не реальная угроза.

Гораздо вероятнее последствия, которые не измеряются рублями. Приложение удаляют из магазина до снятия претензии. Продукту отказывают во включении в реестр. Инвестор или фонд не даёт денег, потому что цепочка прав неясна. Заказчик не принимает работу.

5.6. За границей: один код, много законов

Библиотека, которую вы скачали с GitHub, написана, скорее всего, не в России. Почему её автор защищён российским законом, а ваш код – американским и немецким? Потому что авторское право устроено как сеть договоров между государствами.

Основа сети – Бернская конвенция 1886 года, в которой сейчас участвуют 182 страны; Россия присоединилась к ней в 1995 году. Два её правила определяют всё остальное. Первое: автор из любой страны-участницы получает в каждой другой стране те же права, что и местные авторы. Второе: охрана не зависит ни от каких формальностей – ни от регистрации, ни от знака ©. Код охраняется с момента написания сразу во всех этих странах.

О программах в конвенции позапрошлого века, конечно, ничего нет. Их добавили два более поздних договора. Соглашение ТРИПС, обязательное для всех членов Всемирной торговой организации, записало, что программы в исходном и в объектном коде охраняются как литературные произведения. Оно же закрепило обратную сторону: охраняется выражение, а не идеи, методы и математические понятия. Договор Всемирной организации интеллектуальной собственности 1996 года добавил два запрета, с которыми разработчик сталкивается постоянно: нельзя обходить технические средства защиты и нельзя удалять сведения об авторе и условиях использования. Стереть из чужого файла шапку с именем автора и лицензией – отдельное нарушение, а не небрежность.

При этом единого мирового авторского права нет. Договоры только обязывают каждую страну охранять чужие произведения по своим законам. Был ли нарушен запрет, решает суд той страны, где код использовали, и по её закону: российский суд применит Гражданский кодекс, немецкий – немецкий закон. Один и тот же поступок может быть оценён по-разному. В Европейском союзе, например, купленную бессрочную лицензию разрешено перепродать, а в США перепродажу коробок с программой суд признал незаконной, потому что покупатель был лицензиатом, а не собственником копии.

Суды разных стран за тридцать лет ответили на несколько вопросов, важных для каждого разработчика:

Три вывода из этой таблицы. Открытые лицензии – не декларации о намерениях, а действующие документы, и суды разных правовых традиций приходят к одному результату. Бесплатность не освобождает от условий. А идею, алгоритм и формат данных авторское право не защищает: написать свою программу, которая делает то же самое, можно; копировать чужой текст – нельзя.

Самый простой способ не зависеть от того, чей закон применят, – выполнять текст лицензии буквально. Тогда спора не возникает ни в одной стране.

Почитать на Хабре: «Open Source vs. Public Domain: юридические ловушки свободного ПО» – открытая лицензия как договор, зарубежные и российские судебные дела.

И кодекс, и конвенции, и сами лицензии написаны в расчёте на то, что программу пишет человек. Последние три года это перестало быть само собой разумеющимся.

6. Новые вопросы: код, который написал ИИ

Законы об авторском праве писались для мира, в котором программы пишут люди. В 2026 году заметную часть кода пишет ИИ-агент, и три вопроса, о которых раньше не задумывались, пришлось решать судам. Чей это код? На чём училась модель и не выдаст ли она чужое? На каких условиях распространяются сами модели?

6.1. Чей код написал агент

По российскому закону автором может быть только человек: гражданин, творческим трудом которого создан результат. Верховный суд разъяснял, что техника сама по себе авторства не отменяет: произведение может быть создано с помощью технических средств, но если творческой работы человека не было, как у камеры наблюдения, снимающей в автоматическом режиме, то и охранять нечего. Нейросеть автором быть не может; вопрос только в том, достаточен ли вклад человека, который ею пользовался.

Российские суды уже отвечали на него, и по-разному. В споре о рекламном ролике с подменой лица ответчик утверждал, что ролик создан нейросетью и потому никому не принадлежит. Три инстанции с ним не согласились: сценарий, съёмка и звук были трудом авторов, а нейросеть служила инструментом обработки; взыскано 500 тысяч рублей. А в 2025 году районный суд в Москве отказал в защите дизайнеру, чьи изображения, сделанные с помощью нейросети и доработанные в редакторе, напечатали на футболках. По мнению суда, давать команды искусственному интеллекту – простые механические действия; решение обжалуется. Практика не устоялась, но общая черта у решений есть: всё решает доказанный творческий вклад человека.

В США к тому же пришли раньше. Изобретатель несколько лет добивался, чтобы автором картины записали созданную им программу; в марте 2025 года апелляционный суд ответил, что закон требует автора-человека, а в марте 2026-го Верховный суд отказался пересматривать дело. Ведомство по авторскому праву США разъяснило и то, что касается людей, работающих с ИИ: одних запросов к модели недостаточно, чтобы считаться автором результата. Человеку принадлежит то, что сделал он сам: написанный им текст, отбор и расположение материала, переработка сгенерированного.

Из этого следует неприятный вывод. Код, который агент написал целиком по одному запросу, может не охраняться авторским правом вовсе. Тогда команда не сможет запретить другим его копировать, а лицензия, которую она поставит на такой код, в этой части окажется пустой. Охраняется вклад человека: архитектура, постановка задач, отбор вариантов, правки. Поэтому историю работы стоит хранить: запросы, черновики, коммиты с собственными изменениями.

Показательны правила, которые в 2026 году приняли разработчики ядра Linux. ИИ-агент не вправе ставить под изменением подпись, которой автор подтверждает, что имеет право внести этот код: подтвердить происхождение может только человек. Он же отвечает за совместимость кода с лицензией ядра, а участие ассистента отмечается отдельной пометкой.

Второй слой – условия самого сервиса. Первый российский закон об искусственном интеллекте, вступивший в силу 1 сентября 2026 года, вопрос об авторстве не решает, но отсылает именно к ним: с марта 2027 года те, кто предоставляет доступ к большим моделям, обязаны сообщать пользователю, кому принадлежат права на результат. Почти все поставщики пишут, что на результат не претендуют. Но бесплатные и личные тарифы часто не допускают коммерческого использования, а защищать пользователя от чужих исков поставщики берутся только по платным корпоративным договорам, и то с исключениями.

Есть и третье условие, о котором легко забыть: перечень стран, где сервис работает. Россия и Беларусь в перечни поддерживаемых стран Anthropic и OpenAI не входят, а GitHub Copilot по экспортным правилам США в эти страны не поставляется. Работа в обход такого ограничения – нарушение условий сервиса, и рассчитывать на обязательства поставщика в этом случае нельзя.

6.2. На чём модель училась и что она может выдать

Модели учатся на огромных собраниях текстов и кода, и авторы этих текстов судятся с разработчиками моделей. Картина к осени 2026 года такова. Обучение на законно полученных книгах американский суд первой инстанции счёл добросовестным использованием, а скачивание миллионов книг с пиратских сайтов – нет; это дело закончилось мировым соглашением на 1,5 миллиарда долларов. Немецкий суд дважды решил, что модель, выдающая по простому запросу текст или мелодию известной песни, нарушает права авторов и отвечает за это поставщик. Единой линии нет, но для команды проекта важно одно: риск за обучение несёт поставщик модели.

Риск команды в другом – в том, что модель выдаст. Программисты, подавшие иск к GitHub, утверждали, что ассистент иногда воспроизводит их код почти дословно, но без имени автора и текста лицензии. В сентябре 2026 года апелляционный суд отклонил их требование по одной из норм, однако спор о нарушении условий открытых лицензий продолжается. Насколько часто такое случается, измеряли. Сама площадка оценивает долю предложений, совпадающих с опубликованным кодом, меньше чем в один процент. Независимое исследование четырнадцати моделей дало близкий порядок: от 0,88 до 2,01 % выданного кода оказалось поразительно похожим на существующие открытые реализации, причём большинство моделей не могли правильно назвать лицензию такого кода, особенно если это копилефт. Редко, но при тысячах сгенерированных строк не пренебрежимо.

Самый свежий сюжет на эту тему случился в марте 2026 года. Сопровождающий библиотеки chardet для Python, распространявшейся под LGPL, переписал её целиком с помощью ИИ-агента и выпустил новую версию под разрешительной лицензией MIT. Автор исходной библиотеки возразил: агент видел прежний код, значит, это не независимая разработка, а переделка, и менять лицензию никто не вправе. Через три недели лицензию сменили ещё раз, теперь на отказ от прав; по объяснению сопровождающего, так он обошёл сам вопрос о том, охраняется ли сгенерированный код. Суда не было, и спор не решён. Но урок ясен уже сейчас: переписать код агентом не значит снять с него копилефт.

Отсюда несколько правил работы с ассистентом:

• включить, если он есть, фильтр совпадений с опубликованным кодом;
• крупные законченные фрагменты – целую функцию с характерными комментариями, нетривиальный алгоритм – проверять поиском по коду до того, как они попадут в основную ветку;
• не просить «написать как в библиотеке такой-то»;
• если в выдаче появилась шапка с чужим именем или текстом лицензии, не стирать её, а выяснить источник;
• отмечать в истории коммитов, что сгенерировано, каким инструментом и на каком тарифе.

6.3. Лицензии на модели и данные

Модель – такой же компонент проекта, как библиотека, и у неё есть лицензия. Слово «открытая» в описании модели значит меньше, чем кажется. В 2024 году организация OSI определила, что такое открытый ИИ: должны быть доступны веса модели, полный код обучения и запуска и сведения о данных, достаточные, чтобы специалист построил такую же систему, и всё это на условиях без ограничений по применению. Большинство моделей, которые называют открытыми, этому определению не отвечают. У них опубликованы веса, а к весам приложена лицензия с условиями. Для таких моделей есть более точное название – модели с открытыми весами.

Условия при этом бывают любыми, и внутри одного семейства они разные:

То же относится к данным. Набор изображений ImageNet разрешено использовать только для некоммерческих исследований и обучения. У набора COCO под открытой лицензией распространяется разметка, а права на сами изображения остаются у их авторов. Набор LAION вообще не содержит изображений: это список ссылок с подписями. Модель, обученная на данных «только для исследований», в коммерческом продукте остаётся под вопросом, даже если её код открыт.

Почитать на Хабре: «Кто автор? О правах на код, написанный с помощью искусственного интеллекта»; «У кого права на сгенерированный AI код или картинку и как их защитить».

Теперь известно всё, что нужно для проверки: какие бывают условия, что говорит закон и где появились новые неясности. Осталось сложить это в порядок действий.

7. Можно ли продавать свой проект: порядок проверки

Вопрос «можно ли это продавать» кажется юридическим, но на девять десятых он технический: нужно выяснить, из чего собран продукт, и прочитать условия каждой части. Юрист понадобится в конце, для нескольких спорных строк, и разговаривать с ним гораздо проще, когда на столе лежит готовая таблица.

7.1. Шесть шагов

Опись. Выписывается всё чужое, что вошло в продукт или понадобилось, чтобы его сделать. Не только библиотеки: об этом следующий подраздел.

Лицензия. Для каждой позиции устанавливается лицензия той версии, которая стоит в проекте, и записывается её идентификатор и ссылка на текст. Идентификаторы берут из списка SPDX: это общий словарь, которым пользуются реестры пакетов, сканеры и GitHub. Сейчас в нём около семисот действующих обозначений вроде MIT, Apache-2.0, GPL-3.0-or-later. Если компонент предлагает лицензии на выбор, идентификаторы соединяют словом OR: запись MIT OR Apache-2.0 значит, что получатель выбирает сам.

Класс. Лицензия относится к одному из типов раздела 3: отказ от прав, разрешительная, слабый, сильный или сетевой копилефт, только некоммерческая, особые условия. Восьмой класс – «не установлено»: с ним продукт выпускать нельзя.

Способ. Одна и та же лицензия даёт разные ответы в зависимости от того, как компонент использован и как продукт попадёт к людям. Библиотека под GPL в настольной программе, которую раздают пользователям, требует открыть код программы; та же библиотека в сервисе, который работает на вашем сервере, этого не требует. Поэтому на этом шаге записывают три вещи: меняли ли вы код компонента, соединён ли он с вашим кодом в одну программу и уходят ли копии к пользователям.

Обязанности. Для каждой строки выписывается, что требуется сделать: приложить текст лицензии, упомянуть автора, передать исходный код, показать подпись на карте, купить тариф.

Вывод. Условия всего продукта определяет самая требовательная строка таблицы. Если в проекте сорок библиотек под MIT и одна под AGPL, продукт подчиняется AGPL. Поэтому вывод делают не «в среднем», а по худшему случаю: можно, можно при условиях или нельзя, пока не сделано то-то.

7.2. Что входит в опись

Файл зависимостей – только часть описи. Полезно помнить историю открытия исходных текстов игр Doom и Quake: их разработчики выпустили движки под GPL, но уровни, графика и звук остались закрытыми. Движок, код игры и её материалы – три разных вопроса, и то же верно для любого проекта.

Последняя строка самая незаметная. Ответы на Stack Overflow распространяются под CC BY-SA: скопированный оттуда фрагмент формально требует указать автора и отдать производное на тех же условиях. Строчка из трёх операторов никого не интересует, а перенесённая целиком функция – уже заимствование, которое следует записать.

7.3. Ловушки

Ниже случаи, в которых условие неочевидно. Они подобраны по траекториям курса. На лицевой стороне карточки – то, как обычно рассуждают, на обороте – как обстоит дело и что с этим делать.

Нейросети и компьютерное зрение

Игры

Данные о Земле и карты

Настольные программы и инструменты

Обучение с подкреплением

7.4. Чем проверять

У каждого шага проверки есть свой инструмент. Почти все они бесплатны и запускаются одной командой.

Команды для проекта на Python и для проекта на JavaScript выглядят так:

# Python: таблица лицензий всех пакетов окружения с адресами проектов
pip install pip-licenses
pip-licenses --format=markdown --with-urls --output-file=licenses.md

# три источника сведений рядом: поле лицензии, классификатор, выражение SPDX
pip-licenses --from=all

# JavaScript: сводка по установленным пакетам
npx license-checker --summary

# второй источник: лицензия конкретной версии пакета, ключ доступа не нужен
curl https://api.deps.dev/v3/systems/pypi/packages/chardet/versions/7.3.0

Последняя команда хорошо показывает, зачем указывать версию. Для библиотеки chardet версии 7.0.0 сервис отвечает MIT, для версии 7.3.0 – 0BSD, а для версии 5.2.0 – non-standard, потому что её авторы записали в метаданных просто «LGPL».

Доверять одному инструменту нельзя, и это не предположение, а результат опыта, проделанного при подготовке конспекта. В пустое окружение Python был поставлен набор из восьми пакетов, обычный для учебного проекта: работа с сетью, вычисления, две обёртки над Qt, детектор объектов, два драйвера баз данных, анализатор кода. Вот что получилось.

• Восемь строк файла зависимостей превратились в 60 установленных пакетов. Проверять нужно все шестьдесят.
• У этих пакетов оказалось 24 разных написания лицензии. Одна и та же MIT записана то как MIT, то как MIT License; BSD – четырьмя способами, в том числе просто «BSD», без числа пунктов.
• Три инструмента дали три ответа о драйвере базы данных psycopg2-binary. Первый показал «LGPL» без номера версии, второй – «нестандартная лицензия», третий – вторую версию LGPL. В файле лицензии, который лежит внутри пакета, написано: LGPL третьей версии или более поздней, с исключением.
• Библиотека ua-parser-js для JavaScript в ветке 1.x распространяется под MIT, а в ветке 2.x – под AGPL. Команда установки без указания версии поставила вторую.
• Пакет opencv-python объявлен под Apache-2.0, и все инструменты с этим согласны. Но внутри него лежит FFmpeg, который распространяется под LGPL, а у пакета PyTorch в поставке 96 файлов с лицензиями вложенных компонентов.

Выводов четыре. Метаданные пакета пишет его автор, и часто небрежно. Совпадение двух инструментов ещё не доказательство: оба могли прочитать одно и то же поле. Пометки «только эта версия» и «или более поздняя», слова OR и AND в выражении лицензии – не мелочи, от них зависит совместимость. И лицензия пакета ничего не говорит о том, что в него вложено.

Организации проверяют лицензии непрерывно: специальные системы анализа состава программ следят за каждой новой зависимостью, а на GitHub проверку можно включить для каждого запроса на слияние. Учебному проекту достаточно одного прогона перед выпуском и повторения при каждом обновлении зависимостей.

7.5. Что делать с находкой

Когда в таблице появилась строка «мешает», выходов четыре.

1. Заменить. Почти у каждого компонента с жёсткими условиями есть замена с мягкими: PySide6 вместо PyQt, YOLOX вместо YOLO от Ultralytics, Valkey вместо Redis. Чем раньше найдена проблема, тем дешевле замена; в последнюю неделю она стоит переписанного модуля.
2. Купить. Если автор предлагает платную лицензию, закрытый продукт оплачивает право не открывать свой код. Для учебного проекта это редко оправданно, для продукта с доходом – обычное дело.
3. Отделить. Копилефт распространяется на программу, в которую вошёл код, а не на всё, что работает рядом. Неизменённая программа под AGPL, запущенная отдельным процессом, условий на ваш код не накладывает. Но граница между «рядом» и «внутри» спорная, и именно такие строки стоит показать юристу.
4. Открыть. Иногда проще всего принять условие: выпустить проект под GPL или AGPL. Продавать его по-прежнему можно; нельзя только запретить покупателю делиться.

Для компонента без лицензии есть пятый выход – написать автору и попросить её добавить. Многие авторы просто не подумали о лицензии и охотно это исправляют.

И последнее замечание. Лицензию на код отозвать нельзя: то, что получено под MIT или GPL, остаётся у вас на этих условиях. Доступ к сервису отозвать можно. В октябре 2024 года из списка сопровождающих ядра Linux по требованию юристов убрали около десятка разработчиков, связанных с российскими компаниями; их код остался в ядре под прежней лицензией. Площадки и облачные сервисы подчиняются законам своих стран и собственным условиям. Поэтому в описи полезно отмечать не только лицензии, но и зависимости от сервисов, а копии критичных библиотек и моделей хранить у себя.

Почитать на Хабре: «Чужой код, своя ответственность: лицензионная чистота, которую важно блюсти» – разбор продукта на основе открытого проекта с копилефтом; «Инструкция по SCA: генерация SBOM, инструменты, отличия» – как получить перечень компонентов в машинном виде.

Тренажёр показывает то, ради чего составляется таблица: вывод меняется не только от состава проекта, но и от способа распространения. Сам вывод всё равно делает человек. А вот составление таблицы можно поручить.

8. Как поручить проверку ИИ-агенту

Опись на пятьдесят строк, полсотни текстов лицензий, сверка версий – работа однообразная, и именно такую хорошо делает ИИ-агент. Он читает файлы зависимостей, запускает сканеры, открывает тексты лицензий и сводит всё в таблицу за несколько минут. Но таблица, которой нельзя верить, хуже, чем отсутствие таблицы: она создаёт ощущение, что проверка проведена. Поэтому сначала о том, где агент ошибается, и только потом о том, как ставить ему задачу.

8.1. Четыре ошибки агента

Вспоминает вместо того, чтобы проверить. Языковая модель знает о лицензиях то, что было в текстах, на которых её обучали. Если ей не велеть открыть файл, она ответит по памяти, а память отстаёт от жизни: раздел 2.7 показал, как известные проекты меняли лицензию от версии к версии. Ответ «Redis распространяется под лицензией BSD» верен для версий по 7.2 включительно и неверен для следующих.

Додумывает. Когда сведений нет, модель склонна дать правдоподобный ответ, а не написать «не знаю». Так появляются лицензии, которых у пакета никогда не было, ссылки, которые никуда не ведут, и даже названия несуществующих пакетов. Это измеряли. В исследовании 2025 года шестнадцать моделей написали больше полумиллиона фрагментов кода: у коммерческих моделей не существовало 5,2 % упомянутых в них пакетов, у открытых – 21,7 %. В работе 2026 года проверили ссылки, которые модели приводили как источники: от 3 до 13 % адресов оказались выдуманными.

Упрощает. «Модель открытая, значит, можно всё» – типичный вывод там, где у кода одна лицензия, у весов другая, а у данных третья (раздел 6.3). Туда же относится смешение «исходный код опубликован» и «открытый код».

Соглашается. На вопрос «это ведь можно продавать?» агент охотнее ответит «да»: формулировка подсказывает желаемый ответ. А если попросить его оценить собственную таблицу, он найдёт её хорошей. Из занятия 2 известно, что именно поэтому в системах из нескольких агентов оценку поручают отдельному агенту.

У всех четырёх ошибок общая причина: агент выдаёт утверждение без доказательства. Значит, задачу надо ставить так, чтобы без доказательства утверждение нельзя было написать.

8.2. Разделение труда

Надёжная схема делит работу между тремя участниками. Факты добывает детерминированный инструмент: сканер зависимостей или реестр пакетов на один и тот же вопрос всегда отвечает одинаково и ничего не додумывает. Агент толкует факты: сводит выводы нескольких инструментов, читает тексты лицензий, относит их к классам, составляет список обязанностей. Решение принимает человек, и он же за него отвечает.

Между агентом и человеком стоит проверка. Она не обязана быть сплошной, но обязана быть независимой: её проводит другой источник, другой человек или другой агент, который не видел рассуждений первого.

8.3. Правила постановки задачи

Правила ниже не придуманы для этого конспекта: они повторяют то, что советуют сами разработчики агентов в своей документации. Дать агенту способ проверить результат. Требовать доказательств, а не заверений. Прямо разрешить ответ «не знаю». Поручать проверку отдельному агенту, который не видел хода работы. Здесь эти советы приложены к одной задаче и записаны в той же форме, что и правила для интерфейсов в занятии 11: когда применять, что сделать, какой мерой измерить, как проверить. Первые шесть относятся к тексту запроса, остальные – к работе с ответом.

Запрос

Ответ

8.4. Запрос-образец

Для сравнения сначала пример того, как делать не надо. В открытых коллекциях готовых агентов есть «инженер по лицензиям». Его описание состоит из роли и общих пожеланий: отслеживать риски копилефта тщательно, проверять зависимости систематически. В нём нет ни одной команды, ни требования доказательств, ни формата результата. У такого агента нет даже права запускать программы: ни один сканер он выполнить не сможет.

Ниже запрос, собранный по правилам. В угловых скобках – то, что команда вписывает сама.

Задача: лицензионная проверка проекта перед возможной продажей.

Контекст
- Проект: <одно предложение о том, что это>.
- Как продукт попадёт к пользователям: <установщик | сборка игры | веб-сервис на нашем сервере>.
- Исходный код: <закрыт | готовы открыть>.
- Доход: <планируется | не планируется>.

Что сделать
1. Составь опись всего чужого в проекте. Источники: файлы зависимостей
   (<requirements.txt, package.json, Packages/manifest.json>), папки с ассетами,
   шрифтами, моделями и данными, обращения к внешним сервисам в коде.
   Зависимости зависимостей тоже включи.
2. Для каждой позиции установи лицензию той версии, которая стоит в проекте.
   Бери её только из первичных источников: вывод <pip-licenses | license-checker>,
   метаданные реестра пакетов, файл LICENSE в репозитории по тегу версии,
   страница условий на сайте правообладателя. По памяти не отвечай.
3. Отнеси каждую позицию к классу: отказ от прав | разрешительная | слабый копилефт |
   сильный копилефт | сетевой копилефт | только некоммерческое | особые условия |
   не установлено.
4. Запиши, какие обязанности возникают при нашем способе распространения.

Формат ответа
Таблица Markdown: № | Компонент | Версия | Где используется | Лицензия (SPDX) |
Источник (ссылка) | Класс | Обязанности | Проверено по источнику (да | нет).
После таблицы три списка: «Мешает продаже», «Можно при условии», «Не установлено».
В первых двух для каждого пункта – что можно сделать: заменить (на что),
купить лицензию, открыть код.

Правила
- Сначала покажи план: какие файлы прочтёшь и какие команды запустишь.
  Дождись моего согласия.
- Если лицензию установить не удалось, пиши «НЕ УСТАНОВЛЕНО» и что нужно,
  чтобы её установить. Не предполагай.
- Если два источника расходятся, запиши оба значения и не выбирай сам.
- Общий вывод «продавать можно» или «нельзя» не делай: его сделает команда.
- Ничего в проекте не меняй и не устанавливай без моего согласия.
  Читать файлы и запускать перечисленные команды можно.
- В конце приложи список выполненных команд, число пакетов в выводе сканера
  и число строк в таблице (они должны совпасть) и перечисли, что ты не проверял.

↓z09_license_prompt.md запрос для лицензионной проверки и запрос для проверяющего агента.

Проверяющему агенту достаётся только готовая таблица и другая задача:

Ты проверяешь чужую работу. Ниже таблица лицензий проекта.
Твоя задача – найти в ней ошибки, а не подтвердить её.
Для каждой строки открой указанный источник и проверь:
1) ссылка существует и относится именно к этой версии;
2) идентификатор лицензии совпадает с тем, что написано в источнике;
3) класс лицензии определён верно;
4) у компонента нет второй лицензии и отдельных условий для весов модели или данных.
Выведи только строки с расхождениями и строки, которые проверить не удалось.
Если расхождений нет, перечисли, какие строки и чем ты проверил.

Запрос, который используют постоянно, удобно превратить в файл правил для агента, как это делалось в занятии 11: тогда его не нужно вставлять каждый раз, агент подгрузит правила сам, когда речь зайдёт о лицензиях.

↓z09_license_skill.md заготовка файла правил (skill) для лицензионной проверки.

8.5. Найдите ошибки сами

Есть шесть признаков, по которым видно, что отчёту агента верить нельзя, ещё до всякой проверки:

• у пакетов не указаны версии;
• лицензии названы словами, а не идентификаторами;
• нет ни одной выполненной команды и её вывода;
• все ссылки ведут на главную ветку репозитория, а не на нужную версию;
• нет ни одной строки «не установлено»;
• строк в отчёте меньше, чем пакетов в окружении.

Ниже учебный отчёт. Так мог бы ответить агент на запрос в одну строку – «Проверь лицензии зависимостей и скажи, можно ли продавать» – о настольной программе на Python, которая находит объекты на спутниковых снимках, имеет закрытый код и должна продаваться. Отчёт составлен для упражнения: в него заложены ошибки всех четырёх видов из раздела 8.1. Источников в нём нет, и часть строк неверна.

У всех ошибок этого отчёта одно происхождение: утверждение без источника. С запросом из раздела 8.4 большинство из них стало бы заметно сразу, потому что каждую строку пришлось бы подтвердить ссылкой на текст лицензии нужной версии.

Почитать на Хабре: «У нас есть для вас пакет! Как LLM придумывают несуществующие зависимости» – пересказ исследования о выдуманных пакетах.

Осталось применить всё это к собственному проекту.

9. Задание: лицензионный паспорт проекта

Всё изложенное сводится в один документ – лицензионный паспорт проекта. Он отвечает на вопрос, с которого начался конспект: можно ли отдать проект людям и можно ли брать за него деньги. Работа рассчитана на команду и на ИИ-агента; агент составляет таблицу, команда проверяет её и делает вывод.

1. Опись. Выпишите всё чужое в проекте по девяти категориям из раздела 7.2. Если кода ещё нет, берите то, что записано в плане проекта: движок, язык, библиотеки, источники данных.
2. Факты. Запустите сканер своей экосистемы (таблица в разделе 7.4) и сохраните вывод в файл. Для того, чего сканер не видит, – ассетов, моделей, данных, сервисов – выпишите адреса страниц с условиями.
3. Агент. Отдайте агенту запрос из раздела 8.4 вместе с выводом сканера. Сохраните и запрос, и ответ: они войдут в паспорт.
4. Проверка. Примените правила 7–10 из раздела 8.3. Каждую проверенную строку заносите в журнал: что утверждал агент, чем проверяли, совпало ли. Найденная ошибка агента – не неудача, а результат работы; опишите её.
5. Свой код. Запишите, кто авторы проекта, есть ли между вами письменное соглашение и нет ли третьих лиц с возможными правами: заказчика, работодателя, фонда (раздел 5.2).
6. Вывод. Напишите пять–восемь предложений по схеме аргумента из занятия 3. Утверждение: продавать можно, можно при условиях или нельзя. Данные: строки таблицы, на которых вывод держится. Связка: почему из них это следует при вашем способе распространения. Оговорка: что осталось непроверенным и при каком изменении проекта вывод перестанет быть верным.
7. Репозиторий. Положите в корень репозитория файл LICENSE с лицензией собственного кода и файл THIRD_PARTY_NOTICES.md со списком чужих компонентов и их лицензий. Если команда решила лицензию не выбирать, так и напишите в README: «все права сохранены».

↓z09_license_passport.md бланк лицензионного паспорта: опись, списки, журнал проверки, вывод.

Паспорт принимается, если выполнены четыре условия:

• в описи есть позиции не меньше чем четырёх категорий, а не одни библиотеки;
• у каждой строки указаны версия и ссылка на текст лицензии;
• в журнале не меньше восьми проверенных строк, и для каждой сказано, чем она проверена;
• вывод следует из таблицы и содержит оговорку.

Абзац с выводом пригодится дважды: в отчёте, в главе о проектировании, где обосновывается выбор технологий (справка «Структура отчёта и ВКР», раздел 4), и на защите, когда комиссия спросит, чьи компоненты использованы в работе.

10. Проверь себя

Задание на соответствие проверяет четыре вещи: помните ли вы, чего требует каждая лицензия, умеете ли вы оценить типовую ситуацию, знаете ли, каким инструментом отвечать на вопрос, и какая норма закона за что отвечает.

Контрольные вопросы

• Что такое лицензия и почему код без лицензии использовать нельзя?
  Лицензия – разрешение правообладателя использовать произведение определёнными способами и на определённых условиях; право при этом остаётся у автора. Программа охраняется с момента создания, а отсутствие запрета не считается согласием. Открытый доступ к исходному тексту разрешением не является.
• Какими тремя способами платят за чужой код?
  Деньгами – проприетарная лицензия. Упоминанием – разрешительная лицензия требует сохранить имя автора и текст лицензии. Взаимностью – копилефт требует отдать свой код дальше на тех же условиях.
• Что такое копилефт и зачем он был придуман?
  Приём, при котором автор использует своё авторское право, чтобы запретить запрещать: каждый, кто распространяет программу или её переделку, обязан дать получателю те же свободы и исходный текст. Придуман, чтобы улучшенную версию свободной программы нельзя было закрыть.
• Чем сильный копилефт отличается от слабого и от сетевого?
  Слабый (LGPL, MPL) требует открыть только изменения в самом компоненте. Сильный (GPL) распространяется на всю программу, в которую вошёл код. Сетевой (AGPL) добавляет обязанность предложить исходный код и тем, кто пользуется программой по сети.
• Когда срабатывает условие GPL?
  При передаче копий программы другим людям. Пока программа работает внутри команды или на собственном сервере, копии не передаются и обязанность открывать код не возникает. AGPL закрывает именно случай сервиса.
• Что Apache-2.0 добавляет к условиям MIT?
  Явную патентную лицензию от каждого участника, которая прекращается для того, кто подаст патентный иск, и порядок упоминания: пометки об изменённых файлах и содержимое файла NOTICE.
• Почему лицензии с доступным исходным кодом не считаются открытыми?
  Определение открытого кода не допускает ограничений по области применения и запрета продажи. SSPL и BUSL ограничивают предоставление программы как услуги или коммерческое использование, а пометка «некоммерческое» запрещает получение дохода.
• Как читать правило совместимости лицензий?
  Код движется от более свободных лицензий к более требовательным, но не обратно: MIT можно включить в проект под Apache-2.0, GPL и в закрытый продукт, а GPL – только в проект под GPL. Вторая версия GPL без пометки «или более поздней» не сочетается ни с Apache-2.0, ни с третьей версией.
• Что изменилось в лицензиях GitHub с 2020 по 2026 год?
  Доля MIT выросла с 44,9 до 50,1 %, доля GPL-3.0 снизилась с 11,6 до 9,3 %, а доля AGPL-3.0 выросла больше чем вдвое, с 1,5 до 3,2 %. Копилефт не исчезает, а меняет состав.
• Какая доля открытого кода опубликована без лицензии?
  По исследованию 2026 года – 83 % из 131 миллиона проектов. Чем строже отбор, тем доля меньше: в реестрах пакетов от 8 до 24 %, среди компонентов коммерческих продуктов – 8 %. У 63,7 % моделей на Hugging Face лицензия не указана.
• Кому принадлежат права на программу, написанную командой студентов?
  Самим авторам, совместно. Вуз правообладателем не становится: трудовых отношений нет. Пользоваться общим кодом может каждый, но продать продукт, выдать лицензию или опубликовать код под открытой лицензией можно только вместе; доходы по умолчанию делятся поровну.
• Что такое открытая лицензия по Гражданскому кодексу?
  Договор присоединения, условия которого доступны всем до начала использования. Если срок не указан, для программ она действует весь срок исключительного права, территория – весь мир, плата не взимается. Эта статья делает MIT, GPL и Creative Commons действующими договорами в России.
• Что пользователь программы вправе делать без разрешения автора?
  Запускать её и хранить в памяти компьютера, приспосабливать к своей технике, исправлять явные ошибки, сделать резервную копию, изучать и испытывать её работу, а при соблюдении условий – декомпилировать ради совместимости со своей программой.
• Чем грозит нарушение исключительного права на программу?
  Компенсацией от десяти тысяч до десяти миллионов рублей либо в двойном размере стоимости экземпляров или права использования. Для проекта, который зарабатывает, ответственность наступает независимо от вины. Чаще всего последствия не денежные: удаление из магазина, отказ во включении в реестр, отказ инвестора.
• Почему автор из другой страны защищён российским законом?
  Бернская конвенция, в которой участвуют 182 страны, даёт автору из любой страны-участницы те же права, что и местным авторам, и без всяких формальностей. При этом нарушение оценивает суд той страны, где код использовали, и по её закону.
• Чей код написал ИИ-агент?
  Автором может быть только человек. Код, выданный моделью целиком по одному запросу, может не охраняться вовсе; охраняется вклад человека: архитектура, отбор, правки. Условия сервиса определяют, можно ли использовать результат коммерчески. И сгенерированный фрагмент может повторять чужой код под копилефтом.
• Что такое «три лицензии одной модели»?
  У модели отдельно лицензируются код, веса и данные, на которых она обучена. Открытая лицензия кода ничего не говорит о весах и данных: веса могут быть «только для исследований», а данные – «только для некоммерческого использования».
• Назовите шесть шагов лицензионной проверки.
  Опись всего чужого. Лицензия каждой позиции в той версии, что стоит в проекте. Класс лицензии. Способ использования и распространения. Обязанности. Вывод по самой требовательной строке.
• Какие четыре ошибки делает ИИ-агент, когда его спрашивают о лицензиях?
  Вспоминает вместо того, чтобы проверить, и потому отстаёт от смены лицензий. Додумывает лицензии, ссылки и даже пакеты. Упрощает: путает лицензию кода, весов и данных. Соглашается с тем ответом, который подсказан вопросом.
• Как проверить таблицу лицензий, составленную агентом?
  Сверить число строк с выводом сканера. Открыть источник каждой строки из списков «мешает» и «при условии». Проверить выборку остальных по второму источнику. Отдать таблицу другому агенту с задачей найти ошибки. При расхождении инструментов читать текст лицензии внутри пакета установленной версии.

Источники

Лицензионное соглашение и код без лицензии

1. Obar J. A., Oeldorf-Hirsch A. The biggest lie on the Internet: ignoring the privacy policies and terms of service policies of social networking services // Information, Communication & Society. — 2020. — Vol. 23, No. 1. — P. 128–147. — DOI: 10.1080/1369118X.2018.1486870.
2. Licensing a repository. — Текст : электронный // GitHub Docs : [сайт]. — URL: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository (дата обращения: 12.10.2026).
3. GitHub Terms of Service. — Текст : электронный // GitHub Docs : [сайт]. — URL: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service (дата обращения: 12.10.2026).
4. No License. — Текст : электронный // Choose a License : [сайт]. — URL: https://choosealicense.com/no-permission/ (дата обращения: 12.10.2026).

История лицензий

5. Software Industry. — Текст : электронный // Engineering and Technology History Wiki : [сайт]. — URL: https://ethw.org/Software_Industry (дата обращения: 12.10.2026).
6. An Open Letter to Hobbyists. — Текст : электронный // Wikipedia : свободная энциклопедия. — URL: https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists (дата обращения: 12.10.2026).
7. Timeline 1950–1997. — Текст : электронный // U.S. Copyright Office : [сайт]. — URL: https://www.copyright.gov/timeline/timeline_1950-1997.html (дата обращения: 12.10.2026).
8. Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3d Cir. 1983) : [решение Апелляционного суда третьего округа США от 30.08.1983]. — Текст : электронный // Public.Resource.Org : [сайт]. — URL: https://law.resource.org/pub/us/case/reporter/F2/714/714.F2d.1240.82-1582.html (дата обращения: 12.10.2026).
9. Williams, S. Free as in Freedom: Richard Stallman's Crusade for Free Software. Chapter 1: For Want of a Printer / S. Williams. — Sebastopol : O'Reilly, 2002. — Текст : электронный. — URL: https://www.oreilly.com/openbook/freedom/ch01.html (дата обращения: 12.10.2026).
10. Stallman, R. Initial Announcement / R. Stallman. — Текст : электронный // GNU Operating System : [сайт]. — 1983. — URL: https://www.gnu.org/gnu/initial-announcement.html (дата обращения: 12.10.2026).
11. Stallman, R. About the GNU Project / R. Stallman. — Текст : электронный // GNU Operating System : [сайт]. — URL: https://www.gnu.org/gnu/thegnuproject.html (дата обращения: 12.10.2026).
12. Что такое свободная программа? — Текст : электронный // Операционная система GNU : [сайт]. — URL: https://www.gnu.org/philosophy/free-sw.ru.html (дата обращения: 12.10.2026).
13. McKusick, M. K. Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable / M. K. McKusick. — Текст : электронный // Open Sources: Voices from the Open Source Revolution. — Sebastopol : O'Reilly, 1999. — URL: https://www.oreilly.com/openbook/opensources/book/kirkmck.html (дата обращения: 12.10.2026).
14. Stallman, R. The BSD License Problem / R. Stallman. — Текст : электронный // GNU Operating System : [сайт]. — URL: https://www.gnu.org/licenses/bsd.html (дата обращения: 12.10.2026).
15. Haff, G. The mysterious history of the MIT License / G. Haff. — Текст : электронный // Opensource.com : [сайт]. — 2019. — 26 апр. — URL: https://opensource.com/article/19/4/history-mit-license (дата обращения: 12.10.2026).
16. Torvalds, L. Notes for linux release 0.01 / L. Torvalds. — Текст : электронный // The Linux Kernel Archives : [сайт]. — 1991. — URL: https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 (дата обращения: 12.10.2026).
17. Torvalds, L. Release notes for linux v0.12 / L. Torvalds. — Текст : электронный // The Linux Kernel Archives : [сайт]. — 1992. — URL: https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.12 (дата обращения: 12.10.2026).
18. History of the Open Source Initiative. — Текст : электронный // Open Source Initiative : [сайт]. — URL: https://opensource.org/history (дата обращения: 12.10.2026).
19. The Open Source Definition. — Текст : электронный // Open Source Initiative : [сайт]. — URL: https://opensource.org/osd (дата обращения: 12.10.2026).
20. Creative Commons Unveils Machine-Readable Copyright Licenses. — Текст : электронный // Creative Commons : [сайт]. — 2002. — 16 дек. — URL: https://creativecommons.org/2002/12/16/creativecommonsunveilsmachinereadablecopyrightlicenses/ (дата обращения: 12.10.2026).
21. We Launched. — Текст : электронный // The GitHub Blog : [сайт]. — 2008. — 10 апр. — URL: https://github.blog/news-insights/the-library/we-launched/ (дата обращения: 12.10.2026).
22. Choosing an Open Source License. — Текст : электронный // The GitHub Blog : [сайт]. — 2013. — 15 июля. — URL: https://github.blog/open-source/choosing-an-open-source-license/ (дата обращения: 12.10.2026).
23. MongoDB Issues New Server Side Public License For MongoDB Community Server. — Текст : электронный // MongoDB : [сайт]. — 2018. — 16 окт. — URL: https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-license-for-mongodb-community-server (дата обращения: 12.10.2026).
24. The SSPL is Not an Open Source License. — Текст : электронный // Open Source Initiative : [сайт]. — 2021. — 19 янв. — URL: https://opensource.org/blog/the-sspl-is-not-an-open-source-license (дата обращения: 12.10.2026).
25. Elasticsearch Is Open Source. Again! — Текст : электронный // Elastic Blog : [сайт]. — 2024. — 29 авг. — URL: https://www.elastic.co/blog/elasticsearch-is-open-source-again (дата обращения: 12.10.2026).
26. Redis is now available under the AGPLv3 open source license. — Текст : электронный // Redis : [сайт]. — 2025. — 1 мая. — URL: https://redis.io/blog/agplv3/ (дата обращения: 12.10.2026).
27. Bromberg, M. Unity is Canceling the Runtime Fee / M. Bromberg. — Текст : электронный // Unity : [сайт]. — 2024. — 12 сент. — URL: https://unity.com/blog/unity-is-canceling-the-runtime-fee (дата обращения: 12.10.2026).
28. NTP, Inc. — Текст : электронный // Wikipedia : свободная энциклопедия. — URL: https://en.wikipedia.org/wiki/NTP,_Inc. (дата обращения: 12.10.2026).
29. Edge, J. The rise of copyright trolls / J. Edge. — Текст : электронный // LWN.net : [сайт]. — 2017. — 2 мая. — URL: https://lwn.net/Articles/721458/ (дата обращения: 12.10.2026).
30. Linux Kernel Enforcement Statement. — Текст : электронный // The Linux Kernel documentation : [сайт]. — URL: https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html (дата обращения: 12.10.2026).
31. Doctorow, C. A Bug in Early Creative Commons Licenses Has Enabled a New Breed of Superpredator / C. Doctorow. — Текст : электронный // Pluralistic : [блог]. — 2022. — 24 янв. — URL: https://pluralistic.net/2022/01/24/a-bug-in-early-creative-commons-licenses-has-enabled-a-new-breed-of-superpredator/ (дата обращения: 12.10.2026).
32. Фототролли: рост исков за изображения — схемы, судебная практика и советы юристов. — Текст : электронный // Коммерсантъ : [сайт]. — 2025. — 29 июля. — URL: https://www.kommersant.ru/doc/7923653 (дата обращения: 12.10.2026).
33. Gründe für GPL-Urteil veröffentlicht. — Текст : электронный // ifrOSS — Institut für Rechtsfragen der Freien und Open Source Software : [сайт]. — 2004. — URL: https://www.ifross.org/artikel/gruende-fuer-gpl-urteil-veroeffentlicht (дата обращения: 12.10.2026).
34. Carmack, J. readme.txt : [файл репозитория id-Software/Quake] / J. Carmack. — Текст : электронный // GitHub : [сайт]. — 1999. — URL: https://raw.githubusercontent.com/id-Software/Quake/master/readme.txt (дата обращения: 12.10.2026).

Тексты лицензий и справочные страницы

35. GNU General Public License, version 3. — Текст : электронный // GNU Operating System : [сайт]. — 2007. — URL: https://www.gnu.org/licenses/gpl-3.0.txt (дата обращения: 12.10.2026).
36. GNU Affero General Public License, version 3. — Текст : электронный // GNU Operating System : [сайт]. — 2007. — URL: https://www.gnu.org/licenses/agpl-3.0.txt (дата обращения: 12.10.2026).
37. Apache License, Version 2.0. — Текст : электронный // The Apache Software Foundation : [сайт]. — 2004. — URL: https://www.apache.org/licenses/LICENSE-2.0.txt (дата обращения: 12.10.2026).
38. Mozilla Public License, version 2.0. — Текст : электронный // Mozilla : [сайт]. — 2012. — URL: https://www.mozilla.org/en-US/MPL/2.0/ (дата обращения: 12.10.2026).
39. Attribution 4.0 International: Legal Code. — Текст : электронный // Creative Commons : [сайт]. — URL: https://creativecommons.org/licenses/by/4.0/legalcode.en (дата обращения: 12.10.2026).
40. Frequently Asked Questions. — Текст : электронный // Creative Commons : [сайт]. — URL: https://creativecommons.org/faq/ (дата обращения: 12.10.2026).
41. SIL Open Font License : official text : version 1.1 // SIL International : [сайт]. — URL: https://openfontlicense.org/open-font-license-official-text/ (дата обращения: 12.10.2026). — Текст : электронный.
42. Open Data Commons Open Database License (ODbL) : summary. — Text : electronic // Open Data Commons : [website]. — URL: https://opendatacommons.org/licenses/odbl/summary/ (дата обращения: 12.10.2026).
43. Business Source License 1.1. — Текст : электронный // MariaDB : [сайт]. — URL: https://mariadb.com/bsl11/ (дата обращения: 12.10.2026).
44. Various Licenses and Comments about Them. — Текст : электронный // GNU Operating System : [сайт]. — URL: https://www.gnu.org/licenses/license-list.html (дата обращения: 12.10.2026).
45. Stallman, R. License Compatibility and Relicensing / R. Stallman. — Текст : электронный // GNU Operating System : [сайт]. — URL: https://www.gnu.org/licenses/license-compatibility.html (дата обращения: 12.10.2026).
46. Frequently Asked Questions about the GNU Licenses. — Текст : электронный // GNU Operating System : [сайт]. — URL: https://www.gnu.org/licenses/gpl-faq.html (дата обращения: 12.10.2026).
47. SPDX License List. — Текст : электронный // Software Package Data Exchange (SPDX) : [сайт]. — URL: https://spdx.org/licenses/ (дата обращения: 12.10.2026).
48. Ultralytics License. — Текст : электронный // Ultralytics : [сайт]. — URL: https://www.ultralytics.com/license (дата обращения: 12.10.2026).
49. Obligations of the GPL and LGPL // The Qt Company : [сайт]. — URL: https://www.qt.io/licensing/open-source-lgpl-obligations (дата обращения: 12.10.2026). — Текст : электронный.

Данные об использовании лицензий

50. GitHub Innovation Graph : [набор данных] / GitHub. — Version 1.0.11. — 2026. — 7 July. — URL: https://github.com/github/innovationgraph (дата обращения: 12.10.2026). — Набор данных : электронный.
51. Open source license usage on GitHub.com. — Текст : электронный // The GitHub Blog : [сайт]. — 2015. — 9 марта. — URL: https://github.blog/open-source/open-source-license-usage-on-github-com/ (дата обращения: 12.10.2026).
52. Jahanshahi, M. The Prevalence and Impact of Licenses in Open Software Projects / M. Jahanshahi, B. Vasilescu, A. Mockus. — Текст : электронный // arXiv : [сайт]. — 2026. — 22 June. — arXiv:2606.23445. — URL: https://arxiv.org/abs/2606.23445 (дата обращения: 12.10.2026).
53. O'Grady, S. The State of Open Source Licensing in 2026 / S. O'Grady. — Текст : электронный // RedMonk : [сайт]. — 2026. — 25 марта. — URL: https://redmonk.com/sogrady/2026/03/25/open-source-licensing-2026/ (дата обращения: 12.10.2026).
54. Vidal, N. The most popular licenses for each language in 2023 / N. Vidal. — Текст : электронный // Open Source Initiative : [сайт]. — 2023. — 7 December. — URL: https://opensource.org/blog/the-most-popular-licenses-for-each-language-2023 (дата обращения: 12.10.2026).
55. Vidal, N. Top Open Source licenses in 2025 / N. Vidal. — Текст : электронный // Open Source Initiative : [сайт]. — 2025. — 17 December. — URL: https://opensource.org/blog/top-open-source-licenses-in-2025 (дата обращения: 12.10.2026).
56. Searching for repositories. — Текст : электронный // GitHub Docs : [сайт]. — URL: https://docs.github.com/en/search-github/searching-on-github/searching-for-repositories (дата обращения: 12.10.2026).
57. 2026 Open Source Security and Risk Analysis Report : Software Governance in the AI Era / Black Duck Software, Inc. — 2026. — 44 p. — URL: https://www.blackduck.com/content/dam/black-duck/en-us/reports/rep-ossra.pdf (дата обращения: 12.10.2026). — Текст : электронный.
58. Jennings, T. Open Source Licenses in 2022: Trends and Predictions / T. Jennings. — Текст : электронный // Mend.io : [сайт]. — 2022. — 27 January. — URL: https://www.mend.io/blog/open-source-licenses-trends-and-predictions/ (дата обращения: 12.10.2026).
59. hugovk/top-pypi-packages : a regular dump of the most-downloaded packages from PyPI. — URL: https://github.com/hugovk/top-pypi-packages (дата обращения: 12.10.2026). — Набор данных : электронный.
60. Models. — Текст : электронный // Hugging Face : [сайт]. — URL: https://huggingface.co/models?license=license:mit (дата обращения: 12.10.2026).
61. Mos.Hub : [платформа для совместной разработки]. — URL: https://hub.mos.ru/explore (дата обращения: 12.10.2026). — Текст : электронный.

Право России

62. Гражданский кодекс Российской Федерации. Часть четвёртая : Федеральный закон от 18.12.2006 № 230-ФЗ : (в действующей редакции) // КонсультантПлюс : справочная правовая система. — URL: https://www.consultant.ru/document/cons_doc_LAW_64629/ (дата обращения: 12.10.2026).
63. Российская Федерация. Законы. О внесении изменений в часть четвертую Гражданского кодекса Российской Федерации : Федеральный закон от 07.07.2025 № 214-ФЗ. — Текст : электронный // Президент России : [сайт]. — URL: http://www.kremlin.ru/acts/bank/52125 (дата обращения: 12.10.2026).
64. О поддержке развития технологий искусственного интеллекта в Российской Федерации : Федеральный закон от 26.07.2026 № 243-ФЗ. — Текст : электронный // Гарант.ру : [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/414552934/ (дата обращения: 12.10.2026).
65. О применении части четвертой Гражданского кодекса Российской Федерации : Постановление Пленума Верховного Суда Российской Федерации от 23.04.2019 № 10. — Текст : электронный // Гарант.ру : [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/72130696/ (дата обращения: 12.10.2026).
66. Обзор практики Суда по интеллектуальным правам по вопросам, возникающим при применении норм Гражданского кодекса Российской Федерации о правовой охране программ для ЭВМ и баз данных : утвержден постановлением президиума Суда по интеллектуальным правам от 18.11.2021 № СП-21/26. — Текст : электронный // Гарант.ру : [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/403072019/ (дата обращения: 12.10.2026).
67. По делу о проверке конституционности пункта 3 статьи 1260 Гражданского кодекса Российской Федерации в связи с жалобой гражданина А. Е. Мамичева : Постановление Конституционного Суда Российской Федерации от 16.06.2022 № 25-П. — Текст : электронный // Гарант.ру : [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/404752871/ (дата обращения: 12.10.2026).
68. Уголовный кодекс Российской Федерации : Федеральный закон от 13.06.1996 № 63-ФЗ. Статья 146. Нарушение авторских и смежных прав. — Текст : электронный // КонсультантПлюс : [сайт]. — URL: https://www.consultant.ru/document/cons_doc_LAW_10699/b683408102681707f2702cff05f0a3025daab7ab/ (дата обращения: 12.10.2026).
69. Об утверждении Порядка проведения государственной итоговой аттестации по образовательным программам высшего образования — программам бакалавриата, программам специалитета и программам магистратуры : Приказ Министерства образования и науки Российской Федерации от 29.06.2015 № 636 : [с изменениями от 04.02.2025]. — Текст : электронный // Гарант : [сайт]. — URL: https://base.garant.ru/71145690/ (дата обращения: 12.10.2026).
70. Об утверждении Правил формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных и единого реестра программ для электронных вычислительных машин и баз данных из государств — членов Евразийского экономического союза, за исключением Российской Федерации : Постановление Правительства Российской Федерации от 16.11.2015 № 1236 : [с изменениями по 13.08.2026]. — Текст : электронный // Гарант : [сайт]. — URL: https://base.garant.ru/71252170/ (дата обращения: 12.10.2026).
71. О проведении эксперимента по предоставлению права использования программ для электронных вычислительных машин, алгоритмов, баз данных и документации к ним, в том числе исключительное право на которые принадлежит Российской Федерации, на условиях открытой лицензии и созданию условий для использования открытого программного обеспечения : Постановление Правительства Российской Федерации от 10.10.2022 № 1804. — Текст : электронный // Гарант : [сайт]. — URL: https://base.garant.ru/405431837/ (дата обращения: 12.10.2026).
72. Решение Арбитражного суда города Москвы от 18.03.2025 по делу № А40-261826/2024. — Текст : электронный // СудАкт : [сайт]. — URL: https://sudact.ru/arbitral/doc/EX0BtgTa1CW0/ (дата обращения: 12.10.2026).
73. Решение Арбитражного суда Калининградской области от 23.09.2025 по делу № А21-134/2025. — Текст : электронный // СудАкт : [сайт]. — URL: https://sudact.ru/arbitral/doc/OGheE75suX5w/ (дата обращения: 12.10.2026).
74. Решение Арбитражного суда Удмуртской Республики от 08.10.2025 по делу № А71-16740/2024. — Текст : электронный // СудАкт : [сайт]. — URL: https://sudact.ru/arbitral/doc/7b22f0gYmfNr/ (дата обращения: 12.10.2026).
75. Решение Арбитражного суда Пермского края от 22.07.2020 по делу № А50-36274/2019. — Текст : электронный // СудАкт : [сайт]. — URL: https://sudact.ru/arbitral/doc/fdSxdx66RI6K/ (дата обращения: 12.10.2026).
76. Крупанин, Ф. Суд признал законным отказ Минцифры включить «Свободный офис» в реестр / Ф. Крупанин. — Текст : электронный // Коммерсантъ. — 2026. — 12 октября (№ 188/П). — С. 10. — URL: https://www.kommersant.ru/doc/9023812 (дата обращения: 12.10.2026).
77. Постановление Суда по интеллектуальным правам от 19.08.2024 № С01-1330/2024 по делу № А40-200471/2023. — Текст : электронный // Гарант.ру : [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/409465965/ (дата обращения: 12.10.2026).
78. Суд проверит, защищается ли авторское право на нейросетевую «Джоконду с вином». — Текст : электронный // РАПСИ : [сайт]. — 2026. — 3 августа. — URL: https://rapsinews.ru/judicial_news/20260803/312080815.html (дата обращения: 12.10.2026).
79. Сафьянников, А. В. Правовые проблемы использования открытого программного обеспечения (open source) / А. В. Сафьянников. — Текст : электронный // Журнал Суда по интеллектуальным правам. — 2022. — № 2 (36). — С. 33–45. — URL: https://www.ipcmagazine.ru/articles/1729149/ (дата обращения: 12.10.2026).
80. Вараксин, М. Патенты и санкции: что происходит с принудительным лицензированием в России / М. Вараксин, А. Ломакина. — Текст : электронный // Право.ru : [сайт]. — 2024. — 17 мая. — URL: https://pravo.ru/story/253021/ (дата обращения: 12.10.2026).
81. Положение о конкурсе «Студенческий стартап» (очередь VII) / Фонд содействия инновациям. — Москва, 2026. — Текст : электронный. — URL: https://fondnid.ru/stud-startup/polozhenie-o-conkurse.pdf (дата обращения: 12.10.2026). — Копия на стороннем сайте.
82. Роспатент в цифрах и фактах 2025 : годовой отчет. — Текст : электронный // Роспатент : [сайт]. — 2026. — URL: https://rospatent.gov.ru/content/uploadfiles/docs/032026/RP-Annual-2025-SHORT-1803.pdf (дата обращения: 12.10.2026).

Международные договоры и зарубежная судебная практика

83. Berne Convention for the Protection of Literary and Artistic Works : Paris Act of July 24, 1971, as amended on September 28, 1979. — Text : electronic // WIPO Lex : [website]. — URL: https://www.wipo.int/wipolex/en/text/283698 (дата обращения: 12.10.2026).
84. Contracting Parties. Berne Convention. — Text : electronic // WIPO Lex : [website]. — URL: https://www.wipo.int/wipolex/en/treaties/ShowResults?search_what=C&treaty_id=15 (дата обращения: 12.10.2026).
85. Agreement on Trade-Related Aspects of Intellectual Property Rights. Part II, Section 1 : Copyright and Related Rights. — Text : electronic // World Trade Organization : [website]. — URL: https://www.wto.org/english/docs_e/legal_e/27-trips_04_e.htm (дата обращения: 12.10.2026).
86. WIPO Copyright Treaty (WCT) : adopted in Geneva on December 20, 1996. — Text : electronic // WIPO Lex : [website]. — URL: https://www.wipo.int/wipolex/en/text/295166 (дата обращения: 12.10.2026).
87. ProCD, Inc. v. Zeidenberg : 86 F.3d 1447 : opinion of the United States Court of Appeals for the Seventh Circuit, June 20, 1996. — Text : electronic // OpenJurist : [website]. — URL: https://openjurist.org/86/f3d/1447 (дата обращения: 12.10.2026).
88. Specht v. Netscape Communications Corp. : 306 F.3d 17 : opinion of the United States Court of Appeals for the Second Circuit, October 1, 2002. — Text : electronic // OpenJurist : [website]. — URL: https://openjurist.org/306/f3d/17 (дата обращения: 12.10.2026).
89. Vernor v. Autodesk, Inc. : No. 09-35969 : opinion of the United States Court of Appeals for the Ninth Circuit, September 10, 2010. — Text : electronic // United States Court of Appeals for the Ninth Circuit : [website]. — URL: https://cdn.ca9.uscourts.gov/datastore/opinions/2010/09/10/09-35969.pdf (дата обращения: 12.10.2026).
90. Jacobsen v. Katzer : 535 F.3d 1373 : opinion of the United States Court of Appeals for the Federal Circuit, August 13, 2008. — Text : electronic // OpenJurist : [website]. — URL: https://openjurist.org/535/f3d/1373 (дата обращения: 12.10.2026).
91. Judgment of the Court (Grand Chamber) of 2 May 2012, SAS Institute Inc. v World Programming Ltd, Case C-406/10. — Text : electronic // EUR-Lex : [website]. — URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62010CJ0406 (дата обращения: 12.10.2026).
92. Judgment of the Court (Grand Chamber) of 3 July 2012, UsedSoft GmbH v Oracle International Corp., Case C-128/11. — Text : electronic // EUR-Lex : [website]. — URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62011CJ0128 (дата обращения: 12.10.2026).
93. Google LLC v. Oracle America, Inc. : No. 18-956 : 593 U.S. 1 : opinion of the Supreme Court of the United States, April 5, 2021. — Text : electronic // Supreme Court of the United States : [website]. — URL: https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf (дата обращения: 12.10.2026).
94. (2021)最高法知民终2063号 : 民事判决书 [Постановление Верховного народного суда КНР от 05.05.2023 по делу о программе VirtualApp и лицензии GPLv3]. — Text : electronic // 最高人民法院知识产权法庭 [Палата по интеллектуальной собственности Верховного народного суда КНР] : [website]. — URL: https://enipc.court.gov.cn/zh-cn/news/view-3655.html (дата обращения: 12.10.2026).
95. Cour d'appel de Paris, pôle 5 — ch. 1, arrêt du 14 février 2024 : Entr'Ouvert / Orange et Orange Business Services. — Texte : électronique // Legalis : [site]. — URL: https://www.legalis.net/jurisprudences/cour-dappel-de-paris-pole-5-ch-1-arret-du-14-fevrier-2024/ (дата обращения: 12.10.2026).
96. Kroah-Hartman, G. MAINTAINERS: Remove some entries due to various compliance requirements : commit 6e90b675cf942e50c70e8394dfb5862975c3b3b2 / G. Kroah-Hartman. — Text : electronic // GitHub : [website]. Repository torvalds/linux. — 2024. — October 18. — URL: https://github.com/torvalds/linux/commit/6e90b675cf942e50c70e8394dfb5862975c3b3b2 (дата обращения: 12.10.2026).
97. Navigating Global Regulations and Open Source: US OFAC Sanctions. — Text : electronic // The Linux Foundation : [website]. — 2025. — January 29. — URL: https://www.linuxfoundation.org/blog/navigating-global-regulations-and-open-source-us-ofac-sanctions (дата обращения: 12.10.2026).
98. GitHub and Trade Controls. — Text : electronic // GitHub Docs : [website]. — URL: https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls (дата обращения: 12.10.2026).

Искусственный интеллект и авторское право

99. No. 25-449. Stephen Thaler, Petitioner v. Shira Perlmutter, Register of Copyrights and Director of the United States Copyright Office, et al. : docket. — Text : electronic // Supreme Court of the United States : [website]. — URL: https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/25-449.html (дата обращения: 12.10.2026).
100. Copyright and Artificial Intelligence. Part 2 : Copyrightability : a report of the Register of Copyrights / U.S. Copyright Office. — January 2025. — Text : electronic // U.S. Copyright Office : [website]. — URL: https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf (дата обращения: 12.10.2026).
101. Bartz v. Anthropic PBC : No. 4:24-cv-05417 : docket. — Text : electronic // CourtListener : [website]. — URL: https://www.courtlistener.com/docket/69058235/bartz-v-anthropic-pbc/ (дата обращения: 12.10.2026).
102. Doe v. GitHub, Inc. : No. 24-7700 : opinion of the United States Court of Appeals for the Ninth Circuit, September 16, 2026. — Text : electronic // United States Court of Appeals for the Ninth Circuit : [website]. — URL: https://cdn.ca9.uscourts.gov/datastore/opinions/2026/09/16/24-7700.pdf (дата обращения: 12.10.2026).
103. Pressemitteilung 16/2026 : Urteil GEMA gegen SUNO : [Az. 42 O 763/25, 31.07.2026]. — Text : elektronisch // Landgericht München I : [Website]. — URL: https://www.justiz.bayern.de/gerichte-und-behoerden/landgericht/muenchen-1/presse/2026/16.php (дата обращения: 12.10.2026).
104. Xu, W. LiCoEval: Evaluating LLMs on License Compliance in Code Generation / W. Xu, K. Gao, H. He, M. Zhou. — Text : electronic // arXiv : [website]. — 2024. — arXiv:2408.02487. — URL: https://arxiv.org/abs/2408.02487 (дата обращения: 12.10.2026).
105. GitHub Copilot code referencing. — Text : electronic // GitHub Docs : [website]. — URL: https://docs.github.com/en/copilot/concepts/completions/code-referencing (дата обращения: 12.10.2026).
106. Corbet, J. The relicensing of chardet / J. Corbet. — Текст : электронный // LWN.net : [сайт]. — 2026. — 5 марта. — URL: https://lwn.net/Articles/1061534/ (дата обращения: 12.10.2026).
107. No right to relicense this project : Issue #327 : [обращение в репозитории chardet/chardet]. — Текст : электронный // GitHub : [сайт]. — 2026. — URL: https://github.com/chardet/chardet/issues/327 (дата обращения: 12.10.2026).
108. AI Coding Assistants. — Текст : электронный // The Linux Kernel documentation : [сайт]. — URL: https://www.kernel.org/doc/html/latest/process/coding-assistants.html (дата обращения: 12.10.2026).
109. The Open Source AI Definition — 1.0. — Текст : электронный // Open Source Initiative : [сайт]. — URL: https://opensource.org/ai/open-source-ai-definition (дата обращения: 12.10.2026).
110. Commercial Terms of Service : effective June 17, 2025. — Text : electronic // Anthropic : [website]. — URL: https://www.anthropic.com/legal/commercial-terms (дата обращения: 12.10.2026).
111. Consumer Terms of Service : effective October 8, 2025. — Text : electronic // Anthropic : [website]. — URL: https://www.anthropic.com/legal/consumer-terms (дата обращения: 12.10.2026).
112. Supported Countries and Regions. — Text : electronic // Anthropic : [website]. — URL: https://www.anthropic.com/supported-countries (дата обращения: 12.10.2026).
113. Terms of Use : [редакция для стран вне ЕЭЗ действует с 01.01.2026 ; Europe Terms of Use обновлены 16.01.2026] // OpenAI : [сайт]. — URL: https://openai.com/policies/terms-of-use/ (дата обращения: 12.10.2026). — Текст : электронный.
114. Пользовательское соглашение об использовании Сервиса GigaChat : обновлено 22 июня 2026 г. — Текст : электронный // Сбер. Документация для разработчиков : [сайт]. — URL: https://developers.sber.ru/docs/ru/policies/gigachat/agreement (дата обращения: 12.10.2026).
115. Условия использования технологий генеративного искусственного интеллекта Яндекса : дата публикации: 24.10.2025. — Текст : электронный // Яндекс : [сайт]. — URL: https://yandex.ru/legal/yagpt_termsofuse/ru/ (дата обращения: 12.10.2026).
116. Llama 4 Community License Agreement. — Text : electronic // Meta for Developers : [website]. — URL: https://dev.meta.ai/llama/llama4/license/ (дата обращения: 12.10.2026).
117. Stability AI Community License Agreement : last updated: July 5, 2024. — Text : electronic // Stability AI : [website]. — URL: https://stability.ai/community-license-agreement (дата обращения: 12.10.2026).
118. FLUX.1 [dev] Non-Commercial License v1.1.1. — Text : electronic // GitHub : [website]. Repository black-forest-labs/flux. — URL: https://github.com/black-forest-labs/flux/blob/main/model_licenses/LICENSE-FLUX1-dev (дата обращения: 12.10.2026).
119. Modified MIT License : [лицензия модели Mistral Medium 3.5]. — Text : electronic // Hugging Face : [website]. — URL: https://huggingface.co/mistralai/Mistral-Medium-3.5-128B/blob/main/LICENSE (дата обращения: 12.10.2026).
120. Лицензионное соглашение YandexGPT-5-Lite-8B. — Текст : электронный // Hugging Face : [сайт]. — URL: https://huggingface.co/yandex/YandexGPT-5-Lite-8B-instruct/blob/main/LICENSE (дата обращения: 12.10.2026).
121. Download : terms of access. — Text : electronic // ImageNet : [website]. — URL: https://www.image-net.org/download.php (дата обращения: 12.10.2026).

Условия распространённых компонентов

122. Unity Editor Software Terms : [ред. от 30.06.2026] // Unity Technologies : [сайт]. — URL: https://unity.com/legal/editor-terms-of-service/software (дата обращения: 12.10.2026). — Текст : электронный.
123. Asset Store Terms of Service and EULA. — Текст : электронный // Unity : [сайт] / Unity Technologies. — 2024. — URL: https://unity.com/legal/as-terms (дата обращения: 12.10.2026).
124. Unreal Engine End User License Agreement // Epic Games : [сайт]. — URL: https://www.unrealengine.com/en-US/eula/unreal (дата обращения: 12.10.2026). — Текст : электронный.
125. License. — Текст : электронный // Godot Engine : [сайт]. — URL: https://godotengine.org/license/ (дата обращения: 12.10.2026).
126. License. — Текст : электронный // Blender : [сайт]. — URL: https://www.blender.org/about/license/ (дата обращения: 12.10.2026).
127. What is PyQt? // Riverbank Computing : [сайт]. — URL: https://www.riverbankcomputing.com/software/pyqt/ (дата обращения: 12.10.2026). — Текст : электронный.
128. FFmpeg License and Legal Considerations. — Текст : электронный // FFmpeg : [сайт]. — URL: https://ffmpeg.org/legal.html (дата обращения: 12.10.2026).
129. InsightFace : README // GitHub : [сайт]. — URL: https://github.com/deepinsight/insightface/blob/master/README.md (дата обращения: 12.10.2026). — Текст : электронный.
130. Frequently Asked Questions // Freesound : [сайт]. — URL: https://freesound.org/help/faq/ (дата обращения: 12.10.2026). — Текст : электронный.
131. Common questions : support // Kenney : [сайт]. — URL: https://kenney.nl/support (дата обращения: 12.10.2026). — Текст : электронный.
132. Условия использования отдельных сервисов «Яндекс Карт» : [дата публикации 01.09.2026] // Яндекс : [сайт]. — URL: https://yandex.ru/legal/maps_api/ (дата обращения: 12.10.2026). — Текст : электронный.
133. Google Maps Platform Terms of Service : [ред. от 26.08.2026] // Google Cloud : [сайт]. — URL: https://cloud.google.com/maps-platform/terms (дата обращения: 12.10.2026). — Текст : электронный.
134. Are there any restrictions on the use or redistribution of Landsat data? // U.S. Geological Survey : [сайт]. — URL: https://www.usgs.gov/faqs/are-there-any-restrictions-use-or-redistribution-landsat-data (дата обращения: 12.10.2026). — Текст : электронный.
135. Legal notice on the use of Copernicus Sentinel Data and Service Information // Copernicus : [сайт]. — URL: https://sentinels.copernicus.eu/documents/247904/690755/Sentinel_Data_Legal_Notice (дата обращения: 12.10.2026). — Текст : электронный.
136. Copyright and License // OpenStreetMap : [сайт]. — URL: https://www.openstreetmap.org/copyright (дата обращения: 12.10.2026). — Текст : электронный.
137. Toolbox Subscription Agreement for Students and Teachers : version 4.2 : [действует с 01.05.2024] // JetBrains : [сайт]. — URL: https://www.jetbrains.com/legal/docs/toolbox/license_educational/ (дата обращения: 12.10.2026). — Текст : электронный.
138. End User License Agreement : NVIDIA CUDA Toolkit : [ред. от 26.01.2026] // NVIDIA Documentation : [сайт]. — URL: https://docs.nvidia.com/cuda/eula/index.html (дата обращения: 12.10.2026). — Текст : электронный.
139. The Arcade Learning Environment : README // GitHub : [сайт]. — URL: https://github.com/Farama-Foundation/Arcade-Learning-Environment/blob/master/README.md (дата обращения: 12.10.2026). — Текст : электронный.
140. Terms of Service : [действует с 03.09.2026] // Suno : [сайт]. — URL: https://suno.com/terms (дата обращения: 12.10.2026). — Текст : электронный.
141. ElevenLabs Terms of Service (non-EEA) : [ред. от 09.10.2026] // ElevenLabs : [сайт]. — URL: https://elevenlabs.io/terms-of-use (дата обращения: 12.10.2026). — Текст : электронный.
142. What is the license for the content I post? // Stack Overflow Help Center : [сайт]. — URL: https://stackoverflow.com/help/licensing (дата обращения: 12.10.2026). — Текст : электронный.
143. Titanic — Machine Learning from Disaster : competition rules // Kaggle : [сайт]. — URL: https://www.kaggle.com/competitions/titanic/rules (дата обращения: 12.10.2026). — Текст : электронный.

Инструменты и методика проверки

144. pip-licenses : Dump the software license list of Python packages installed with pip. — Текст : электронный // GitHub : [сайт]. — 2026. — URL: https://github.com/raimon49/pip-licenses (дата обращения: 12.10.2026).
145. license-checker : check license info for a package. — Текст : электронный // npm : [сайт]. — URL: https://www.npmjs.com/package/license-checker (дата обращения: 12.10.2026).
146. API. — Текст : электронный // Open Source Insights (deps.dev) : [сайт] / Google. — URL: https://docs.deps.dev/api/v3/ (дата обращения: 12.10.2026).
147. ScanCode Toolkit. — Текст : электронный // GitHub : [сайт] / AboutCode. — 2026. — URL: https://github.com/aboutcode-org/scancode-toolkit (дата обращения: 12.10.2026).
148. License Scanning. — Текст : электронный // Trivy : [документация]. — URL: https://trivy.dev/latest/docs/scanner/license/ (дата обращения: 12.10.2026).
149. OSADL Open Source License Checklists. — Текст : электронный // OSADL : [сайт] / Open Source Automation Development Lab eG. — URL: https://www.osadl.org/OSADL-Open-Source-License-Checklists.oss-compliance-lists.0.html (дата обращения: 12.10.2026).
150. OSADL Open Source License Compatibility Matrix. — Текст : электронный // OSADL : [сайт]. — URL: https://www.osadl.org/html/CompatMatrix.html (дата обращения: 12.10.2026).
151. Compatibility Checker. — Текст : электронный // Interoperable Europe Portal : [сайт] / European Commission. — URL: https://interoperable-europe.ec.europa.eu/collection/eupl/solution/licensing-assistant/compatibility-checker (дата обращения: 12.10.2026).
152. Appendix. — Текст : электронный // Choose a License : [сайт] / GitHub, Inc. — URL: https://choosealicense.com/appendix/ (дата обращения: 12.10.2026).
153. REUSE Specification — Version 3.3. — Текст : электронный // REUSE Software : [сайт] / Free Software Foundation Europe. — 2024. — URL: https://reuse.software/spec-3.3/ (дата обращения: 12.10.2026).
154. Licenses. — Текст : электронный // Hugging Face Hub documentation : [сайт]. — URL: https://huggingface.co/docs/hub/repositories-licenses (дата обращения: 12.10.2026).
155. Add required legal files to your package. — Текст : электронный // Unity Manual : [сайт] / Unity Technologies. — URL: https://docs.unity3d.com/Manual/cus-legal.html (дата обращения: 12.10.2026).
156. OpenChain ISO/IEC 5230 — License Compliance. — Текст : электронный // OpenChain Project : [сайт] / The Linux Foundation. — URL: https://openchainproject.org/license-compliance (дата обращения: 12.10.2026).
157. Open Source License Best Practices : Quick Reference Guide. — Текст : электронный // The Linux Foundation : [сайт]. — URL: https://www.linuxfoundation.org/licensebestpractices (дата обращения: 12.10.2026).
158. Licenses. — Текст : электронный // Google Open Source : [сайт] / Google. — URL: https://opensource.google/documentation/reference/thirdparty/licenses (дата обращения: 12.10.2026).

ИИ-агент: постановка задачи и проверка ответа

159. Best practices for Claude Code. — Текст : электронный // Claude Code Docs : [сайт] / Anthropic. — URL: https://code.claude.com/docs/en/best-practices (дата обращения: 12.10.2026).
160. Reduce hallucinations. — Текст : электронный // Claude Platform Docs : [сайт] / Anthropic. — URL: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations (дата обращения: 12.10.2026).
161. Building Effective AI Agents / Erik S., B. Zhang. — Текст : электронный // Anthropic : [сайт]. — 2024. — 19 дек. — URL: https://www.anthropic.com/engineering/building-effective-agents (дата обращения: 12.10.2026).
162. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs / J. Spracklen, R. Wijewickrama, A. H. M. N. Sakib [и др.]. — Текст : электронный // arXiv.org : [сайт]. — 2024. — URL: https://arxiv.org/abs/2406.10279 (дата обращения: 12.10.2026).
163. Rao, D. Detecting and Correcting Reference Hallucinations in Commercial LLMs and Deep Research Agents / D. Rao, E. Wong, C. Callison-Burch. — Текст : электронный // arXiv.org : [сайт]. — 2026. — URL: https://arxiv.org/abs/2604.03173 (дата обращения: 12.10.2026).
164. license-engineer. — Текст : электронный // GitHub : [сайт] / VoltAgent. — URL: https://github.com/VoltAgent/awesome-claude-code-subagents/blob/main/categories/08-business-product/license-engineer.md (дата обращения: 12.10.2026).

Статьи на Хабре

165. WolfffR. Почему корпорации зарабатывают миллиарды на «бесплатном» коде. История Open source / WolfffR. — Текст : электронный // Хабр : [сайт]. — Блог компании Timeweb Cloud. — 2025. — 17 нояб. — URL: https://habr.com/ru/companies/timeweb/articles/960686/ (дата обращения: 12.10.2026).
166. maybe_elf. Молодой Билл Гейтс начал сражаться с первыми в мире пиратами софта 50 лет назад / maybe_elf. — Текст : электронный // Хабр : [сайт]. — 2026. — 2 февр. — URL: https://habr.com/ru/news/991722/ (дата обращения: 12.10.2026).
167. marked-one. Лицензия для вашего open-source проекта / marked-one. — Текст : электронный // Хабр : [сайт]. — 2014. — 13 нояб. — URL: https://habr.com/ru/articles/243091/ (дата обращения: 12.10.2026).
168. Germanlawyer. Опенсорс лицензии: большой разбор лицензий GNU / Germanlawyer. — Текст : электронный // Хабр : [сайт]. — 2025. — 5 дек. — URL: https://habr.com/ru/articles/973728/ (дата обращения: 12.10.2026).
169. ant3mc. Лицензии слабого копилефта: могут ли они заменить пермиссивные (разрешительные) лицензии? / ant3mc. — Текст : электронный // Хабр : [сайт]. — 2026. — 17 апр. — URL: https://habr.com/ru/articles/1024508/ (дата обращения: 12.10.2026).
170. ko_ya. Open Source vs. Public Domain: юридические ловушки свободного ПО / ko_ya. — Текст : электронный // Хабр : [сайт]. — Блог компании Online patent. — 2026. — 25 июня. — URL: https://habr.com/ru/companies/onlinepatent/articles/1051820/ (дата обращения: 12.10.2026).
171. Aleksey999. Когда вендор меняет правила игры: риски смены лицензий БД и что с этим делать / Aleksey999. — Текст : электронный // Хабр : [сайт]. — Блог компании МТС. — 2026. — 11 февр. — URL: https://habr.com/ru/companies/ru_mts/articles/991386/ (дата обращения: 12.10.2026).
172. Растегаев, Ю. Разбираемся с лицензией Redis. И что выбрать продуктовой команде / Ю. Растегаев. — Текст : электронный // Хабр : [сайт]. — 2026. — 8 июля. — URL: https://habr.com/ru/articles/1056598/ (дата обращения: 12.10.2026).
173. alizar. Как компании зарабатывают на опенсорсе, а потом выкидывают его / alizar. — Текст : электронный // Хабр : [сайт]. — Блог компании RUVDS.com. — 2024. — 13 мая. — URL: https://habr.com/ru/companies/ruvds/articles/811679/ (дата обращения: 12.10.2026).
174. Travis_Macrif. MIT и Apache 2.0 лидируют в лицензировании с открытым исходным кодом в 2025 году / Travis_Macrif. — Текст : электронный // Хабр : [сайт]. — 2025. — 22 дек. — URL: https://habr.com/ru/news/979182/ (дата обращения: 12.10.2026).
175. Aleksandr_NFA. Как взвесить чужой репозиторий, не запуская его: 138 проектов из трендов GitHub / Aleksandr_NFA. — Текст : электронный // Хабр : [сайт]. — 2026. — 24 сент. — URL: https://habr.com/ru/articles/1086232/ (дата обращения: 12.10.2026).
176. Максимов, А. Чужой код, своя ответственность: лицензионная чистота, которую важно блюсти / А. Максимов. — Текст : электронный // Хабр : [сайт] : блог компании CodeScoring. — 2026. — 2 окт. — URL: https://habr.com/ru/companies/codescoring/articles/1089624/ (дата обращения: 12.10.2026).
177. Багно, В. Инструкция по SCA: генерация SBOM, инструменты, отличия / В. Багно. — Текст : электронный // Хабр : [сайт] : блог компании Swordfish Security. — 2024. — 5 марта. — URL: https://habr.com/ru/companies/swordfish_security/articles/797801/ (дата обращения: 12.10.2026).
178. Шахтарина, А. Кто автор? О правах на код, написанный с помощью искусственного интеллекта / А. Шахтарина. — Текст : электронный // Хабр : [сайт] : блог компании «Конференции Олега Бунина (Онтико)». — 2025. — 30 сент. — URL: https://habr.com/ru/companies/oleg-bunin/articles/946634/ (дата обращения: 12.10.2026).
179. Семенов, М. У кого права на сгенерированный AI код или картинку и как их защитить / М. Семенов. — Текст : электронный // Хабр : [сайт]. — 2025. — 13 авг. — URL: https://habr.com/ru/companies/cloud_ru/articles/936446/ (дата обращения: 12.10.2026).
180. Максимов, А. У нас есть для вас пакет! Как LLM придумывают несуществующие зависимости / А. Максимов. — Текст : электронный // Хабр : [сайт] : блог компании CodeScoring. — 2026. — 7 авг. — URL: https://habr.com/ru/companies/codescoring/articles/1068000/ (дата обращения: 12.10.2026).
181. Шафигуллин, И. Минцифры смягчил запрет на включение в «реестр» программ с компонентами, лицензируемыми на условиях GPL, MPL / И. Шафигуллин. — Текст : электронный // Хабр : [сайт]. — 2023. — 11 мая. — URL: https://habr.com/ru/articles/734372/ (дата обращения: 12.10.2026).
182. Торвальдс прокомментировал исключение российских разработчиков из списка мейнтейнеров Linux по указанию юристов / denis-19. — Текст : электронный // Хабр : [сайт]. — 2024. — 23 окт. — URL: https://habr.com/ru/news/852962/ (дата обращения: 12.10.2026).